功能安全-26262-理论到实践-基础知识-混合ASIL系统与 独立软件单元

混合ASIL系统 Mixed-ASIL Systems

除了最小的组件(components)，很难发现一个系统只有一个单一的ASIL等级。传统汽车上，一辆车安全相关的系统和诸如娱乐、导航等其他非直接安全相关系统之间是有非常清晰的界限的。安全相关的应用会独立于其他非安全相关应用或者系统按照AUTOSAR(AUTomotive Open System ARchitecture汽车开发系统架构)进行开发。

现在的汽车电子，因为OEM希望通过硬件集成来降低成本，使这种系统之间的物理隔离已经不复存在。现在一颗多核处理器可以处理过去很多颗芯片才能处理的任务，而且传感器也是共享的-这类技术被称为传感器融合(sensor fusion)。假如两个子系统需要同样位置的摄像头背景数据，没有必要安装两个摄像头。

只要两个不同ASIL等级的子系统共享同一个硬件，就会存在隔离(Isolation)的问题。如何保证系统设计能让一个子系统不干扰另外一个？ISO 26262的PART6 附录D和IEC61508的PART3的附录F中列举了在设计过程中，需要保证的不相互干扰的项目，来解决上面的隔离问题。

时延(timing)

我们如何保证一个子系统不会吸收过多的处理时间，导致另一个子系统时间不够用？

死锁(deadlock)和活锁（livelock）

我们如何保证两个共享同一外设的不相关子系统不会形成活锁或者死锁？

内存（memory）

设计如何保证一个子系统不会覆盖另一子系统使用的内存?

消息传递（Messaging）

如果一个子系统运行依赖于另一子系统发送的消息。假如消息出现丢失、损坏、延迟或者重复时，系统如何继续保证安全？

上面提到的几点虽然有用，但是并不完整。大部分的现代操作系统会提供工具来保护内存、公平分配处理器时间、局部隔离外设等。更隐蔽的是子系统和操作系统无法控制的组件之间的交互。许多处理器上(processors)的“隐藏”元素,诸如，指令集(instrutions)，数据高速缓存(data catches)，张量(Tensor)，图形编程单元(GPU graphic programming units)，DMA控制器（controller），NVRAM控制器（controller））以及应用程序共享资源（总线（bus）等），对于应用程序来说是不可见的(invisible)，并且很大程度上无法控制(largely uncontrollable)。在许多处理器(processors)中已发现的安全漏洞(security vulnerabilitie)（如熔断Meltdown和幽灵Spectre）也会使单元之间的隔离减弱。在这种环境中，我们如何保证必要的隔离(isolation)？

独立软件单元SEooC

ISO26262在Part10的第9部分引入了一个概念，即独立软件单元(Safety Element out of Context SEooC)，所谓独立软件单元就是用在某一系统中，但是并非为这个系统专门设计的软件单元。假如一个汽车系统需要一个数据库，开发人员不需要从新开发数据库，直接使用MySQL就可以了。这时MySQL就是独立软件单元。当开发者使用独立软件单元时(无论是即用型(out of the box)还是修改的(modification)，需要说清楚需求并且保证SEooC可以满足这些需求。假如SEooC来自于第三方系统安全理论，系统开发人员需要SEooC的bug报告并且分析SEooC的bug是否会影响到系统的安全。这是非常繁重的任务(onerous task)，比如Linux 内核的软件bug列表不仅长而且还是不断调整的。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!