原创
软件分区设计——在航空安全的实践以及对汽车行业的思考
➡本文主要内容分为5个部分（约4000字，10分钟阅读）
与如今汽车电子架构的演变历程一样，航空电子架构也曾经历了从分布式到中央计算+域控的进化，只不过完成进化的时间更早：早在上个世纪末，IMA（Integrated Modular Avionics，集成模块化航空电子设备）的设计理念就已融入到了大型民航客机的研制。在这种架构设计下，从安全等级最高的显控系统、到最低的娱乐系统在内的几十项应用，都被高度集成在一个中央计算机内，由同一个微处理器统一调配运行。我们所熟悉的波音787、空客A380等飞机均采取了这种设计理念。
航电系统的这种架构进化能够有效降低各种使用成本，包括机舱空间、能耗、线束、重量、冷却、安装、维护等各方面。对于对每一克航油的节省都锱铢必较的航空公司，IMA平台相较旧有的分布式架构带来了显著的成本优势。然而，这无疑也会带来安全性问题，在一个集成了不同安全等级应用的计算平台中，类似显控系统、飞控系统等高安全等级软件，必须避免被低安全等级的应用所干扰。软件分区则是实现这一目标的核心工作。
在汽车功能安全领域，ISO26262和AutoSAR等相关标准都提到了软件安全分区的一些设计原则。而航电系统也在数十年的研发和审定过程中，针对软件分区形成了许多宝贵的经验，值得我们思考和借鉴。
《民用航空机载软件适航标准（DO-178）》是由欧美航空组织于80年代初编制、用于保证航空机载软件符合飞行安全要求（即“适航性”）的规范性文件。在DO-178C的2.4.1中明确提出：不论软件分区是通过分配软件组件到不同的硬件资源、还是在一个硬件上运行多个软件组件来实现的，都应该满足以下安全分区的需求[1]：
● 一个分区的软件组件不应被允许破坏另一个分区的软件组件的代码、输入/输出（I/O）、或数据存储区域。
● 一个分区的软件组件应当只有在其得到调度的执行时段中，才被允许使用共享处理器的资源。
● 一个分区的软件组件独有的硬件失效不应对其他分区的软件组件产生不利影响。
● 任何提供分区（机制或服务）的软件，应当具有与分配给任何分区中最高安全等级软件组件相同或更高的安全等级。
● 任何提供分区的硬件应当得到系统级安全评估，以确保它不会对安全性产生不利影响。
而随着上世纪90年代，IMA逐渐应用于航电系统架构，《集成模块化航空电子设备 (IMA) 开发指南和认证问题（DO-297）》提出IMA平台需要提供分区的服务，以便为平台上所承载的共享平台资源的应用提供足够的分隔和隔离，并且在一旦发生失效导致分区机制被破坏时，能够检测到失效并采取失效响应措施，以最终实现“健壮分区（Robust Partitioning）”[2]。
如果分区没有被正确实现，会导致直接影响安全性问题，包括了：
● 错误地写数据到错误的区域；
● 从另一个应用窃取运行时间；
● 使处理器崩溃；
● 破坏I/O;
● 破坏输入数据；
● 独占内部通信通道；
● 破坏共享的闪存文件系统；
● 在向新分区进行上下文切换时引入时间抖动。
显而易见，要实现良好的软件分区设计，绝不是仅仅靠软件工程师能完成的。分区设计是一项高度复杂的系统工程，需要设计人员对系统、硬件和软件体系结构具备深刻的理解。在波音或空客等OEM中，软件分区设计的往往由首席电子架构专家主导完成。
无论是汽车还是航空，要实现所谓的“Robust Partitioning”，主要在计算平台的三个子系统中进行分区设计：内存、中央处理器（CPU）和I/O。
● 共享内存（空间分区设计）
空间分区的根本在于阻止一个分区中的功能破坏或覆盖另一个分区中的某功能的数据空间。一般通过硬件和软件两种方式实现对共享内存的空间分区设计。基于硬件的方式通过CPU自带的MMU或MPU来实现内存访问的权限控制。另一种通过软件的方式则是在每个内存访问点上，对代码加入逻辑校验，通过检查地址寄存器中的内容，确保所访问的内存是正确的[4]。
● 共享CPU（时间分区设计）
时间分区的目标是确保一个分区中的功能不干扰另一个分区中的事件的时间。除了对使用CPU的访问时长、运行速率、延迟、抖动等进行精密地设计外，为确保绝对安全，ARINC 653标准对涉及安全的不同分区采取强制的轮转制度，采用指定的运行时长和周期[3]。而在单个分区内部，则采用其它的调度器。此外，中断设计不当会对时间分区进行破坏，比较保守的方法包括彻底禁止中断来确保安全组件的运行。其他容易破坏时间分区的因素还包括了调度溢出、计时器损坏、控制流缺陷或软件缺陷等。这些因素都需要经安全分析后被识别并验证。
● 共享I/O
共享I/O的种类和作用繁多，包括串口、交换机在内的各种端口、设备、通道都可能被多个分区所共享。共享I/O分区需要同时考虑时间分区和空间分区。ARINC653对于共享I/O提供了取样（Sampling）和队列（Queuing）的操作机制，确保端口被有序使用。
● 分区分析
DO-297要求应开展完整的分区分析（Partitioning Analysis），来表明满足了整个系统的分区要求。该分析过程和系统安全分析类似，分区分析工程师可以通过FTA或FMEA的形式，分析出分区失效链，证明所有影响分区需求的系统性失效或硬件随机失效被识别、分类和控制。DO-297从系统性失效的角度，例举了影响分区设计的潜在失效，从而更好的帮助设计人员自底向上的分区分析[2]：
中断和中断禁止（软件和硬件）；
循环，例如无限循环或间接无终止地调用循环；
实时通信，如时间帧溢出、实时时钟干涉、计数器/计时器破坏、流水线和高速缓存，以及确定性调度；
控制流，例如不正确地从一个分支进入一个分区或受保护地区域、一个跳转表地破坏、处理器顺序控制地破坏、返回地址地破坏，以及不可恢复地硬件状态破坏（如屏蔽和关机）；
内存、输入/输出的竞争；
数据标志共享；
软件陷阱，例如被零除、未实现的指令、特定的软件中断指令、不识别的指令，以及递归终止；
停顿的命令，即性能障碍；
输入或输出数据丢失；
输入或输出数据破坏；
内部数据破坏，例如直接或间接内存写入、表溢出、不正确的链接、涉及时间的计算，以及破坏高速缓存；
延迟的数据；
程序覆盖；
缓冲区顺序；
外部设备交互，例如数据丢失、数据延迟、不正确数据、以及协议停机等。
分区分析从本质上是系统安全分析的扩展，需要与系统安全工程师保持密切协调；并且，与系统安全分析一样，需要在分区开发初期就进行分区分析，并根据开发进展不断更新迭代分区分析结果，直到每一个被识别出的分区失效根因都被完整识别、分析和缓解。
● RTOS SVA分析
分区设计和RTOS是紧密相关的，而操作系统软件本身的“脆弱性（Vulnerability）”，通常也会成为导致分区失效的因素之一。RTOS的脆弱性可以是作为软件本身的一些固有缺陷，如果集成方应对不当，则会对数据一致性、任务、调度、中断、内存访问等造成不利影响。因此，一个完整的分区分析，还需要建立在对操作系统的“软件脆弱性分析（Software Vulnerability Analysis）”的仔细评估的基础上。SVA清单一般都能从RTOS供应商处获得，如航空领域广泛使用的风河VxWorks653。对于分区分析工程师来说，需要将SVA作为分区分析的重要输入之一，识别并分析出RTOS SVA中所述的操作系统异常是否会对分区效果产生潜在的不利影响。
● 数据流/控制流分析
数据流/控制流分析往往和分区分析是两个活动，但却有着微妙的联系：即便分区机制做的再完善，一旦数据流/控制流分析不到位，那不论是不同分区间必要的数据交互、抑或是单个分区内部的数据交互，都可能引入共因失效或级联失效。因此，软件分区不能保证避免数据或控制的耦合出现问题；反之，数据/控制流问题也不意味着分区机制有着缺陷。一个建立在完整数据流/控制流分析之上的分区分析，往往会更有价值。
● 评审Checklist
详细的分区设计评审是必需的，并且需要保证评审的独立性。美国联邦航空局的审定专家Leanna Rierson提出了建议的分区评审清单[4]，便于从数据流和控制流两个维度对分区设计进行检查。
数据流相关：
✔ 分区是否会被数据流破坏？
✔ 共享数据是否会被不恰当使用？
✔ 消息是否会被不正确发送或接收？
✔ 函数参数是否会被不恰当使用？
✔ 配置数据是否会无效？
✔ 数据是否会被不正确传递？
✔ 数据是否会被不正确地初始化？
✔ 全局数据是否会被不正确地读或写？
✔ 全局数据是否会被非预期的函数错误地写？
✔ 全局数据是否会未初始化或者不正确地再次初始化？
✔ 硬件寄存器是否会被不恰当地使用？
✔ 链接器是否会不正确地组装数据或代码？
✔ 数据是否会变得陈腐或无效吗？数据会丢失？
✔ 是否会发生对数据的错误比较的不正确响应？
✔ 是否会出现非预期的浮点值？
控制流相关：
✔ 分区是否会被控制流破坏？
✔ 函数是否会在一个特征内或特征之间被不恰当地调用？
✔ 中断是否会引起错误的行为？
✔ 硬件故障或失效是否会影响数据完好性或执行顺序？
✔ 模式间的转换是否会不正确地实现？
✔ 资源是否会被不恰当地分配？
✔ 非激活代码是否会被不经意地激活？
✔ 初始化顺序是否会不正确？
✔ 是否会发生对异常的不恰当响应？
✔ 故障处理程序是否会动作不恰当(例如,丢失故障或失效，或者不正确地处理故障或失效）？
✔ 是否会发生内存重叠？
✔ 是否会读或写不正确的硬件地址？
✔ 在复位时是否会发生不恰当的响应？
✔ 同步是否会被错误的比较或错误的等待影响？
✔ 不正确的上下文切换是否会引起错误的数据或计时？
✔ 是否会生成任何非预期的异常？
✔ 函数是否会以不正确的速率或时间执行？
● 分区机制的测试
针对分区机制的测试可以通过仿真或台架测试来完成，通过故障注入来制造破坏时间分区和空间分区的情况，从而来证明分区的完好性。严格来说，测试的工作量往往取决于前期识别得到的分区失效根因的数量。但在工程实践中，诸多涉及硬件细节或底层设备驱动的故障难以通过测试来进行，部分将纳入到分区分析中，以安全性分析的形式完成验证。
软件分区设计所面对的绝大部分失效根因，都属于系统性失效。因此，一个优秀的分区设计除了对人员的技术能力有着极高要求，更要求企业具备完整的电子软硬件开发流程，缺乏体系基础的分区设计往往是空中楼阁。航空制造业在漫长的适航安全审定过程中，逐渐建立了严密的研发流程体系。在对安全日益重视的汽车行业，这也必将是国内各汽车OEM的发展方向。
参考文献：
1.《民用航空机载软件适航标准（DO-178）》
2.《集成模块化航空电子设备 (IMA) 开发指南和认证问题（DO-297）》
3.《ARINC653-Avionics Application Software Standard Int-erface》
4.《Developing Safety-Critical Software——A Practical Guide for Aviation Software and DO-178C Compliance》 Leanna Rierson, 2020.
James / 作者
END
免责声明：如涉及侵权请及时与我们联系反馈，我们会在第一时间做更正声明或做删除处理。文章版权及解释权归原作者及发布单位所有，如需转载或引用本文的任何内容，请注明出处。
