越来越多程序设计人员在设计安全相关应用程序时采用ARM处理器，范围遍及医疗、运输、航空电子与工业领域。因此，透过这些处理器所执行的软件也受到更为严格的检查，因为任何一个小错误都有可能导致严重后果。

    为了避免导致这样的后果，包括IEC 61508，还有近才通过的汽车业ISO 26262等安全标准应运而生，以确保开发人员与客户在软件方面能符合业界的实务准则。

    即便如此，要决定标准当中有哪些元素适用，哪些不适用，接下来还要确保整体设计符合标准，整个过程非常耗时以致于令人却步。由于消费类器件的设计周期极短且逐渐与汽车安全系统整合，开发人员也因此面临更大的时间压力，必须在日益紧迫的设计周期期限前完成设计改动。

    所幸针对软件开发工具与相关作业，软件系列工具厂商具备一般软件开发人员所没有的信息与知识，因此在市场中具有独特定位，能为所有安全相关软件开发人员提供支持。

    对编译器来说更是如此，因为编译器能直接影响系统安全性，而且其有可能产生的注入错误，后续功能设计测试却无法检测。因此，系列软件工具组很适合那些使用基于ARM处理器的开发人员，能使开发人员确保系统符合法规规范，并同时应付日益增加的产品上市时间的压力。

    ARM 处理器逐渐拓展应用

    伴随移动的风潮，加上持续扩展的生态系统提供支持，基于ARM处理器的应用已从智能手机与嵌入式等器件，拓展到基础架构设备及数据服务器。现在，设计人员也逐渐开始将它们导入安全相关的应用。

    这类应用涵盖了工业（马达控制、工厂自动化、远距监控）；汽车（底盘控制、车身与安全、仪表板、智能传感器、引擎控制、防抱死刹车）；医疗（注入泵、起搏器、病患监控）；铁路（信号与通讯控制）；核能（控制面板、马达控制、系统监控）与航空电子等领域。

    图 1 ： ARM处理器横跨消费类与数据服务器应用领域，打入汽车电子、工业电子等各种产业，然而在这些领域当中，IEC 61508、ISO 26262等标准所规范的功能性安全需求，为微控制器软件开发社群带来了新的压力。

    整体而言，系统对智能功能的需求增加，带动了ARM处理器为市场所广泛采用，但这也要求业者必须具备整合能力与弹性以降低成本，提供更多功能，并随时更新系统。与此同时，许多采用硬编码逻辑来提供各种功能的设计，现在都逐渐整合到由软件所控制的32位微控制器，从而又产生出新的问题。

    设计重心逐渐移转至微控制器与程序编码功能，也同时将安全问题推向软件领域，让安全应用程序符合IEC 61508标准的责任，也因此落在软件开发人员的肩上。这套标准原本规范的是电气与／或电子系统的功能安全性，现在则同时涵盖安全系统的电子组件。

    图 2 ： IEC 61508及相关产业专用标准，能协助安全相关的电气、电子与可编程系统符合要求。

    功能性安让安全相关系统针对输入做出正确响应，进而避免不必要的直接或间接风险以及损伤。

    由于IEC 61508标准用语模糊，因此衍生出各种产业专用的标准，例如专供铁路运输使用的EN50126/8/9、医疗器件专用的IEC 60601、核能专用的IEC 60880，还有陆上交通工具专用的ISO 26262。 ISO 26262适用于3,500公斤以下量产客用车的安全相关系统，但不包括残障专用等特殊用途车辆。

    一般汽车里的微控制器往往多达150个，而随着消费者导向的导航系统被整合到驾驶辅助、运动检测系统、推进、车载动态控制与主动／被动安全系统时，汽车逐渐成为运算装置涉足安全系统的一个研究。

    安全系统开发人员所面临的压力与日俱增，汽车也成为典型。相较于过去动辄长达3到10年的产品生命周期，现在还得配合消费类装置（12到18个月）的设计周期。

    汽车里的150个微控制器都仰赖软件程序运转，有时甚至像编译器这样的基本组件也会造成系统故障，只因注入了不容易发现的错误，并在功能测试阶段有可能无法检测。

    这会对系统持续造成风险，但只要符合IEC 61508标准，再加上ISO 26262，就能将风险降至可以容忍的程度。举例来说，IEC 61508实务准则建议一开始就要使用可以信赖的工具。

    一般普遍认为编译器是T3分类的离线支持工具，表示编译器会直接或间接影响安全系统的可执行代码，因此选择编译器“是有其正当性的”。[IEC 61508-3 Section 7.4.4.3]

    我们可以藉由通过验证且正在使用的实证，来展现工具的成熟度与稳定性，再加上来自业界的第三方评估以及厂商担保，藉此证明选择的正当性。

    实务准则还能加以延伸，用来验证输出以及语言子集的使用，像是MISRA C/C++。测试目标所使用的软件自然重要，但要如何得知已经测试了每种可能发生的状况？毕竟没有执行的程序代码就无法测试。这时就要利用代码覆盖率分析，来辨识尚未执行的程序代码，进而确保整个应用程序均已测试完毕。分析代码覆盖率可利用源代码插装或跟踪数据，因为串流跟踪的影响程度。

    至于语言子集，在许多当中，高阶程序设计语言的定义不完整或模糊不清，造成不同编译器的行为也有所不同。

    “严格模式”，还有MISRA C/C++之类的语言子集，就是为了消除这些模棱两可的状况所设计，同时还能：确保使用的语言与标准语言一致；替未定义的行为设定规则；移除免工具使用选项；强制统一编码式样（例如：/*...*/ versus //）；改善可读性；并缩小整体所需测试范围。

    ISO 26262比IEC 61508更进一步，提供的架构更讲究细节，在这样的架构下可考虑采用以其它技术为基础所开发的安全系统。涵盖范围从产品周期管理到供货商关系，但对于软件开发人员来说，它提供了一种专为汽车设计、以风险为基础的方法来评判完整性，而这套方法就称为汽车安全完整性等级（Automotive Safety Integrity Levels; ASILs）。

    使用ASILs明确定义ISO 26262的适用要求，以避免不合理的剩余风险，同时提供验证需求与确认措施，以确保达到足够且可接受的安全程度。

    建议：遵守默认标准

    好消息是，在ISO 26262公布后才开始的设计，并不一定要遵循其设计指南，才能成就“”的设计准则并取得法律保护。不过聪明的业者会强制遵循其广泛的标准，因为传统上说这确实是一种好的做法也能确保一致性，同时还能降低成本，因为目前不包括在标准里的要求，很可能明天就会被列入，所以从一开始就加以制度化。

    但要同时符合IEC 61508与ISO 26262，每个步骤都必须准备说明文件，从离线工具使用的合理性，一直到工具行为、手册、危险分析、编译器缺失、历史版本、测试，还有实际及预期结果的差异，都只是其中少数几个项目。

    这样的说明文件需要投入极大心力，花费时间且成本昂贵，这时软件系列工具供货商就能派上用场。他们是工具的。举例来说，他们熟知编译器如何运作、如何利用安全应用程序，也了解如何利用它来取得既定输出并利于安全相关开发。

    ARM Compiler系列软件工具就是一个很好的使用，它近取得了德国安全技术检验机构TüV SüD的。取得该后客户便能将ARM Compiler建立工具应用在安全相关开发，可达安全完整性等级第三级(SIL3, IEC 61508)以及汽车SILD(ASILD, ISO 26262)，而无须进行其他合格验证。还有ARM Compiler 规范套件可扩充TüV SüD验证功能，其中包括安全手册、缺失、测试与开发程序做为支持数据。

    图 3 ： 对于生产汽车应用程序可编程系统的业者来说，要符合IEC 61508与ISO 26262软件功能安全要求，就必须提供大量说明文件与。

    这样的第三方与支持厂商保证，能即时节省人员工时、投入心力与相关成本，同时还能让产品或设计更快上市，甚至可以保证应用程序设计还会继续被市场所采用，因为在快速设计周期的时代，时间就是一切。