11-8 AEB 产品软件需求

2023-11-11 15:30
文章标签 产品软件 需求 aeb

本文主要是介绍11-8 AEB 产品软件需求,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

按照ASPICE规范的要求,需要聚焦系统需求、系统架构设计、软件需求及软件架构设计等4部分核心内容。本章是在11-7 AEB 产品系统架构的基础上,重点讲述软件需求部分。

1. 软件需求规范

版本

概述

范围

功能需求

非功能需求

2. AEB软件架构

2.1 视觉感知

目标的输入

状态的输入

2.2 雷达感知

目标的输入

状态的输入

2.3 感知融合

Yaw rate

Brake pressure

Longitudinal acceleration

Wheel speed

Wheel angle

Standstill

Brake lights

Activation /deactivation menu-button

3. AEB FCW功能

功能实现简述:

Brake System: 

ego velocity
maximal velocity reductionthreshold
maximal decelerationthreshold
vehicle stability
EBA:driver deceleration thresholds
driver take over conditions

3.1 感知状态

3.1.1 标定状态

0x0 状态正常

0x1 感知故障

0x2 未标定

0x3 标定成功

0x4 标定失败

0x5 正在标定

3.1.2 遮挡状态

0x1未遮挡

0x2 部分遮挡

0x3全部遮挡

3.1.3 感知目标信号输出

信号数据类型

信号源

3.1.4 目标选择

TTC TTLC TTB

3.2 驾驶员输入

功能开关

HU

HU_AEBState

0x0无变化

0x1 on

0x2 off

功能输出

HU_AEBState

0x0默认开

0x1 off

FCW敏感度调节

HU_FCWSen

              0x0

0x1

0x2

ADAS_FCWSen

0x0

0x1

0x2

油门

制动

挡位

安全带

车门状态

3.3 车辆状态

轮速信号

ESC

纵向加速度

EPB故障或者拉起

APA

3.4 执行器执行

当ADAS_AEBDecReq == 0x1

当ADAS_AEBDecValue

==0.3g

==0.5g

==1.g

EPB

       车速<1.5kph

              ADAS_ESChold 0x1

当收到ESC_EPBstate 0x1 applied AEB功能退出

              AEB:

                     持续发ADAS_AEBDecReq == 0x1

和ADASAEBDecValue

==0.3g

==0.5g

==1.g

当收到ESC_EPBstate 0x1 applied AEB功能退出

             

ESC_Standsitll 0x1

ADAS_ESChold 0x1

当收到ESC_EPBstate 0x1 applied AEB功能退出

3.5 状态机

参见系统需求详细分析

3.6 场景判断

依E-CNAP 2023标准展开:

CCR

VRU

CM

3.7 查表

本车速度、目标车速度和TTC关系输出目标减速度

3.8 FCW

图示

图示+声音

图示+声音+点刹

3.9 HMI

参见AEB算法架构

这篇关于11-8 AEB 产品软件需求的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/391057

相关文章

十四、我们应当怎样做需求分析:子用例与扩展用例

用例模型作为UML中4+1视图中非常重要的一员,非常集中地体现了面向对象的分析与设计思想。用例模型将现实世界中连续的一个一个业务流程,按照场景划分到了一个一个的用例中。由于场景的出现,使得用例中的业务流程存在着高度的内聚性,从而成为了日后各种对象的雏形。同时,在用例分析中,又将那些存在于各个用例中的,相同或相近的业务操作提取出来,形成一个一个的子用例或扩展用例,又体现了面向对象设计中的复用性。现在

十三、我们应当怎样做需求分析:查询报表分析

在我以往的用例分析中,使用这样格式的用例模式,对于大多数业务操作流程来说是得心应手的,但对于有些功能来说总感觉不对劲。感觉不对劲的,就是那些查询、汇总与报表功能。对于这部分功能,需要我们描述的不是什么操作流程,而更重要的是那些数据项、数据来源、报表格式、数据链接,以及使用者、使用频率的说明。而这些,在以往的用例说明格式中统统都没有,怎么办呢?俗话说“东西是死的人是活的”,把我们的用例格式改改吧。

九、我们应当怎样做需求分析:功能角色分析与用例图

在我们进行一系列需求调研工作的同时,我们的需求分析工作也开始启动了。需求调研与需求分析工作应当是相辅相伴共同进行的。每次参加完需求调研回到公司,我们就应当对需求调研的成果进行一次需求分析。当下一次开始进行需求调研时,我们应当首先将上次需求分析的结果与客户进行确认,同时对需求分析中提出的疑问交给客户予以解答。这就是一个需求捕获->需求整理->需求验证->再需求捕获的过程。  但是,当我们经

八、我们应当怎样做需求调研:需求捕获(下)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

七、我们应当怎样做需求调研:需求捕获(上)

前面我们讨论了,需求分析工作是一个迭代的过程:需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始,也是整个需求分析工作中最重要的部分。没有捕获哪来后面的整理与验证工作?但是,非常遗憾,按照我以往的经验,需求捕获是我们最薄弱的环节。前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题,而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。需求捕获是整

六、我们应当怎样做需求调研:迭代

前面我一直在反复强调这样一个观点,需求分析不是一蹴而就的,是一个反复迭代的过程。它将从第一次需求分析开始,一直持续到整个项目生命周期。为什么这样说呢?让我们一起来分析分析。  在第一次的需求分析阶段,我们在一段时期内需要与客户进行反复地讨论,这个过程往往是这样一个反复循环的过程:需求捕获->需求整理->需求验证->再需求捕获••••••  需求捕获,就是我们与客户在一起开研讨会

五、我们应当怎样做需求调研:需求研讨

前面我们探讨了业务研讨会应当怎样组织,下面我们再具体讨论一下我们应当怎样与客户讨论业务需求。如果说组织业务研讨会是项目经理的功底,那么讨论业务需求就是需求分析人员的功底。  以往我们常常认为,需求分析是一件最简单的事情。客户说他们需要做一个什么软件,有些什么功能,我们照着做就可以了,所谓的需求分析员就是需求的记录员。我要说,这是一个极大的错误,许多失败的软件项目,或者说软件项目中的需求问

AI超周期现状 - NVIDIA、苹果以及人工智能的整体需求

于2024年6月6日在中国杭州拍摄的英伟达和苹果的标志。到6月5日,东部时间,英伟达的市值超过3万亿美元,正式超越苹果的市值,成为全球市值第二大的科技巨头。值得注意的是,短短3个多月时间里,英伟达的市值就从2万亿美元飙升至3万亿美元。(由Costfoto摄于NurPhoto,经盖蒂图片社批准) 在九月初经历了几天的市场动荡后,又有一波关于人工智能超级周期是否已结束的讨论。如果没有结束,那接下来会

从需求场景下出发实操Clickhouse

背景 本着以实时数仓为目标调研了几款OLAP引擎,像Clickhouse、Kylin、Druid等,在粗略了解其架构后,并且在接受各个大厂Clickhouse实践、高性能测试报告、最近业界发展势头凶猛的熏陶与PUA情况下,不得已选择了Clickhouse,当然自己也做过一些测试,本篇将介绍clickhouse的一些原理、实践方案(可能还未实现、可能并不是最佳)与遇到的一些问题,总之只是希望能

数据库课程设计mysql---图书管理系统详细的设计文档和需求文档

图书管理系统设计文档与需求文档 一、项目概述 项目名称:图书管理系统 项目背景:随着图书馆规模的扩大和图书数量的增加,传统的手工管理方式已难以满足现代图书馆高效、精准的管理需求。因此,开发一套基于MySQL的图书管理系统,旨在通过信息化手段实现图书的录入、借阅、归还、查询及用户管理等功能的自动化,提高图书馆的工作效率和服务质量。 项目目标: 实现图书信息的电子化存储与管理。提供便捷的图书