汽车功能安全——软件架构设计

1、软件架构的定义

        软件架构（Software Architecture）是软件系统的基础结构，它描述了系统的组成部分、它们之间的关系以及指导这些组成部分设计和演进的原则和方针。软件架构不仅关注系统的功能需求，还关注非功能需求，如性能、可维护性、可扩展性、安全性等。

1b. 语法和语义定义均不完整的描述方法：存在不完整性和二义性的问题

1c. 语法定义完整、但语义定义不完整的描述方法，如Simulink和Statefolw等

①语法定义完整：

• 定义明确：汽车功能安全在语法层面上的定义是清晰和明确的。它通常被描述为“不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险”，即确保汽车上的E/E模块在功能失效时不会对人员造成伤害。
• 结构清晰：在语法结构上，汽车功能安全的定义包含了关键元素，如“电子电气系统”、“功能异常表现”、“危害”和“不合理的风险”，这些元素共同构成了完整的定义框架。

②语义定义不完整：

• 复杂性：尽管语法定义明确，但汽车功能安全的语义定义可能因其复杂性和多样性而不完整。这是因为功能安全不仅涉及产品功能本身，还包括需求、研发、验证、生产、运行、维保等整个产品生命周期内的所有活动及管理过程。
• 多维度考量：功能安全的语义定义需要考虑多个维度，如严重度（S）、暴露概率（E）和可控性（C）等。这些维度共同决定了功能安全的等级（如ASIL A-D），但单一维度的等级很高时，并不一定属于安全等级，可能属于质量管控（QM）。
• 动态变化：汽车功能安全的语义定义还可能随着技术进步、标准更新和市场需求的变化而发生变化。这使得语义定义的完整性更加难以保证。

1d. 语法和语义均被完整定义的描述方法

2、软件架构的设计原则

1a. 软件组件之间应采用分层结构，组件之间通过接口（全局变量或函数名称）交互；

1b. 软件组件设计要合理，遇到复杂逻辑可以拆分为多个组件，圈复杂度不能太高；

1c. 软件组件的接口数量不能太多，接口数量的增加会导致软件组件复杂度的升高；

1d&1e. 软件组件内部要实现功能内聚，软件组件之间要降低耦合；

1f. 设计合理的软件调度顺序（优先级及周期），确保每个任务能被完整执行；

1g. 减少中断的使用，提高系统稳定性，运行效率提高；

1h. 组件之间除设计接口外不能互相干扰；

1i. 要对共享资源进行管理，常见的共享资源包括：供电、时钟和驱动等。

3.软件架构的静态设计

包含应用层软件架构，服务层软件架构，ECU抽象层架构，MCU抽象层架构设计。

描述方法：通过静态框图描述软件架构，框图中需标注软件所属层级，功能安全等级等信息。

4、软件动态架构设计

动态设计需要包含：

①. 事件和行为的功能链：动态架构设计中，需要明确事件如何触发系统的行为，以及这些行为如何组合成功能链，确保系统能够按照预期的顺序和逻辑执行相应的功能；

②. 逻辑顺序和数据处理：架构应清晰地描述系统中各组件之间的逻辑顺序和数据处理流程，确保数据在系统中的传递和处理是准确、高效和可靠的；

③. 控制流和并发进程：在动态架构设计中，需要详细规划控制流，包括条件分支、循环等，以确保系统能够正确地响应各种输入和事件。同时，对于并发进程的管理也是关键，需要确保多个进程之间的协调和同步，避免资源冲突和死锁等问题；

④. 通过接口和全局变量传递的数据流：动态架构应清晰地描述数据在系统各组件之间通过接口和全局变量传递的过程。这包括数据的来源、去向、格式和转换方式等，以确保数据的完整性和一致性；

⑤. 时间限制：功能安全标准要求动态架构设计中应考虑到时间限制的要求，例如任务的响应时间、系统的吞吐量等。架构应确保系统能够在规定的时间内完成任务，满足用户的实时性需求。

5、软件架构设计注意事项

a. 软件架构设计既要考虑软件安全需求，又要考虑其它软件需求；

b. 软件架构设计是对整体软件架构的设计，不一定局限于某个微控制器或ECU；

c. 软件组件应按照分配给它的所有需求的最高的ASIL等级来进行开发；

d. 软件架构设计应被开发到能够识别出软件单元（最小软件单元为一个函数）的程度；

e. 如果嵌入式软件的最高等级为ASIL D，需要对软件组件行适当的空间隔离；

f. 应该对嵌入式软件所需资源进行上限预估，包括：时间资源、内存资源和通信资源等；

g. 一个软件分区内的Task，彼此之间不能免于干扰；

h. 一个软件分区不能改变其它软件分区的代码或数据，也不能控制其它软件分区的非共享资源。