越来越多程序设计人员在设计安全相关应用程序时采用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、医疗器件专用的IEC60601、核能专用的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软件功能安全要求，就必须提供大量说明文件与报告。
这样的第三方认证与支持厂商保证，能即时节省人员工时、投入心力与相关成本，同时还能让产品或设计更快上市，甚至可以保证应用程序设计还会继续被市场所采用，因为在快速设计周期的时代，时间就是一切。