AUTOSAR与功能安全的关系（二）
上一篇粗略的说了AUTOSAR如何支持功能安全的软件架构的。这里补充一下其他的点。
在ISO26262的标准中有如下的说明
7.4.2要求软件架构具备可验证性，追溯性，可配置性，灵活性，可测性和可维护性；
7.4.3要求模块化，封装化，简单化。
显然AUTOSAR出于其层次分明，模块独立性强以及其静态代码与配置代码独立的设置等特点，几乎完全的符合了7.4.2的要求。而AUTOSAR具备了以下几种特点
Reusability: 可重用性，规定了模块间的标准接口
Verifiability : 可验证性，依托于工具链提供商的检测
Modularity: 模块化，软硬件的独立性及各层级模块间的独立性
Encapsulation:封装性，基于层级封装的设计
另外在功能安全软件架构设计时，要求静态架构设计和动态架构设计
静态架构设计包含：架构框图，数据流，模块接口等
动态架构设计包含：状态迁移图，时序流，schedule图等
AUTOSAR中对于静态设计的因素有：Compositions, SWCs, Interfaces, Ports,Runnables
UTOSAR中对于动态设计的因素有：OS, Tasks, RTE Events
一般来说都在参考下面这个表
这个表格内容有虚有实，所以我才吐槽ISO26262这一标准的可执行性实在是太差了！
基本上AUTOSAR其自身的模块化层级化，以及interface，swc等因素灵活使用的存在满足1a1b1c
1d1e是软件开发行业中随时随地都会被提到的“高内聚，低耦合”的要求，这个设计就是仁者见仁智者见智了。我想说的是，AUTOSAR出于模块化可剪裁等特点，模块间耦合度已经很低了。至于其内聚的体现，我再研究研究。。
1f和1g是针对AUTOSAR的OS和RTE的来说的，强大的OS功能和灵活的EVENT使用，可实现最合适的调度机制，以及用轮询的EVENT触发方式取代中断的使用（功能安全尽可能不要使用随机中断）。
暂时写到这吧，总结加搬砖，大家轻拍，欢迎讨论
- 用户评论