软件架构中需要实现软件安全要求和非安全相关要求。在软件架构中，应该明确软件单元。由于软件单元获得分配给他们的不同的安全要求，因此，考虑这些要求（可能具有不同的ASIL 等级）是否可以共存于软件单元中也很重要。共存（coexistence）需要满足某些标准。如果不能满足共存的要求，那么软件应该按照分配的最高的功能安全等级来进行开发。这些涉及到的标准可能包括内存保护和保证执行时间。

软件架构包含动态和静态（dynamic and static）两方面。静态方面主要反映出软件单元之间的接口；动态方面主要反映的是时序，比如执行时间和顺序。下图是一个软件架构的简单实例。为了明确这两方面，被使用的软件架构的符号就包含非形式的，半形式的和形式的 （informal, semi-formal, formal）。ASIL 等级越高，需要用到的形式越多。

对于软件架构，同样很重要的是要考虑它的可维护性和可测试性。在汽车环境中，软件需要在全生命周期内具备可维护性。还需要软件架构中的软件可以很容易地进行测试，因为当我们争论软件是否根据ISO 26262满足了安全要求时，测试就是一个很重要的证据和手段。在软件架构设计过程中，我们也可以考虑使用可配置的软件（Configurable software）。当然，这样做优缺点都有。

为了避免高复杂性 (complexity）而带来的软件系统性失效 （Systematic failure），ISO 26262规定了一套适用于不同部分的原则：

· 组件应该具有分层结构，内部高内聚，并限制其大小；

· 软件单元之间的接口应该保持简洁明了（simple and samll）。这可以通过关注点分离来限制软件单元之间的耦合来支持；

· 软件单元的调度需要被考虑，以确保软件单元的执行时间。通常讲，应该避免中断，但如果使用中断应基于优先级；

在软件架构层面，检测不同软件单元之间的错误的可能性很大。一般说来，不同的ASILs, 等级越高，需要的安全机制就越多。下面是ISO 26262提到的一些机制，有一些可能是重叠的。

· 数据范围检查：这是个很简单的方法来确认读出或写入接口的数据在规定的范围值内。任何超出此范围的值都会视为有错误，比如：一个温度低于绝对零度；

· 合理性校验：这是一种完整性的检查，可以用于软件单元之间的信号。它应该，比如：捕捉普通汽车在一秒内从静止到100km/h的车速信号。这种加速度是不合理的，或者说是不可能的。合理性校验可以使用参考模型来比较来自其他信号源的信息，从而检测错误的信号值；

· 检测错误数据：检测错误数据的方法有很多种，比如：用校验和和数据冗余存储来检测代码错误；

· 监控程序执行：为了检测执行中的错误，外部的监控通常效果很好。比如，在不同的MCU或者看门狗中执行的软件；

· 控制流监控：通过监控软件单元的执行流程，可以检测到某些故障，包括跳过指令和软件卡滞在无限循环中；

· 软件多样性设计：在软件设计中使用多样性是有效的。方法是设计两个不同的软件单元互相监控，如果行为不一致，那么就有一个故障需要去处理。但这种方法也可能会受到质疑，因为软件工程师犯类似错误的情况很常见。为避免类似的错误，软件的功能越多样化，这类错误出现的概率就越低；

· 访问权限控制：通过使用在软件或者硬件中实现的访问冲突控制机制，可以通过授予和拒绝访问权限来保护安全相关资源，比如：内存保护单元（MPU）；

一旦检测到错误，就需要立即处理它。ISO 26262中也明确了在软件架构层面来处理错误的机制：

· 停用（Deactivation）：对于某些系统，为了处于安全状态，可能会直接停用功能；

· 静态恢复机制（Static recovery）：目的是从损坏状态恢复进入可以继续正常运行的状态；

· 完美降级/优雅降级（Graceful degradation）：此方法可以使系统从正常运行状态进入到安全状态，当检测到错误的时候。汽车行业常见的例子是通过警告灯告知驾驶员某些东西不工作，比如：安全气囊不可用时的安全气囊警告灯；

· 同构冗余/同质冗余 （Homogenous redundancy）：这种机制侧重于通过具有冗余的硬件单元来控制硬件中的故障。该概念基于硬件同时发生故障的可能性很低并且一个冗余通道应始终安全运行的假设；

· 多样性冗余（Diverse redundancy）：这种机制侧重于通过不同的软件，即不同的实现来控制软件中的设计错误。比如，满足相同安全要求的软件的不同实现，通常是两种不同的实现。这种机制也同样适用于硬件设计错误；

· 纠正数据代码（Correcting codes for data）：对于数据错误，有一些机制可以纠正这些错误。这些机制都是基于添加冗余数据来提供不同级别的保护。使用的冗余数据越多，可以纠正的错误就越多。比如，这通常用于RAM；

当我们的软件架构设计完成后，我们需要验证软件架构是否违反软件的要求。ISO 26262也给出了一些方法：

· 设计走查（Walk-through of the design）：这种方法是同行评审的一种形式，其中软件架构设计人员为评审团队描述架构，目的是发现任何的潜在的问题点；

· 设计检查（Inspection of the design）：与 走查相反，检查更正式一些。它由几个步骤组成，包括计划，线下检查，检查会议，返工作业和变更跟进；

· 仿真（Simulation）：如果软件架构可以仿真，这是一个很有效的方法，尤其是发现架构动态部分的错误；

· 原型测试（Prototype testing）：至于仿真，原型设计对于整个系统来说是非常有效的动态部分。然后，重要的是分析原型和预期目标之间的任何差异；

· 形式化验证（Formal verification）：这是一种在汽车行业中很少使用的方法，用于使用数学证明或反驳正确性。它可以用来确保预期行为，排除非预期的行为，并且证明安全要求；

· 控制流分析（Control Flow analysis）：这种类型的分析可以在静态代码分析期间完成。目的是在执行过程中找到任何安全关键路径在架构层面的软件；

· 数据流分析（Data flow analysis）：这种类型的分析可以在静态代码分析期间完成。目的是在软件架构层面找到软件变量中的安全临界值；

· 时序分析（Scheduling analysis）：目的是确保软件单元的调度完好。它可以通过分析和测试相结合的方法来完成。