如何优化安全和业务关键型嵌入式软件开发

电子说

1.2w人已加入

描述

开发安全或业务关键型软件只需要更多的知识和努力,以确保以不牺牲质量的方式使用工具和技术。

任何优化软件开发过程的尝试都将不可避免地遇到质量、资源和时间之间的古老权衡。这个三重约束对于项目经理来说是众所周知的,格言是只有三分之二才有可能成功。

当然,没有一家公司真的想在质量上妥协,但对于安全关键型或业务关键型软件而言,风险更高,因为在质量上妥协可能会导致严重的财务或危及生命的后果,因此主要关注点必须放在质量上对于此类项目。那么,当项目的性质要求软件质量必须是最重要的时候,您如何优化嵌入式软件开发呢?

培养质量文化
质量文化将减少实现优质产品的开销,并意味着在生产高质量软件时需要更少的有意识的思考和努力。

幸运的是,通过遵循一些简单的原则,发展质量文化相对容易。质量文化倾向于促进透明度和所有权。他们还将测试和质量控制视为开发过程的重要组成部分,而不是最后的开发步骤。

有效的质量文化的基石是良好的沟通。技术包括从每日例会到报告错误时提高清晰度的所有内容,以便在修复错误时不太可能犯错误。跨职能团队和团队之间的密切沟通也有助于促进质量文化,并确保所有利益相关者对质量和安全目标有很好的理解。

优化您的软件开发方法
现代软件开发方法,如敏捷和 DevOps,被广泛认为比传统的瀑布方法产生更快的结果。所有主要的软件安全标准(例如,IEC 61508、ISO 26262 和 DO-178C)都将软件开发定义为一个线性过程,v 模型在左侧显示需求定义,在右侧显示测试,如下图所示:

这使得在开发安全关键软件时很难摆脱线性瀑布方法。现代敏捷开发实践侧重于频繁发布,这可能会给安全关键型软件的开发带来问题,因为每个发布都需要经过正式的验证和/或认证流程。同样,DevOps 原则(例如持续部署)在涉及硬件时会变得更加复杂。

但是,仍然可以利用许多 DevOps 和敏捷原则来创建一种简化的、更具迭代性的方法来开发安全关键型和业务关键型嵌入式项目。

Shift-left
在项目开发生命周期中较早(左)移动工作量通常会导致整体工作量减少。花更多时间确保软件需求和设计正确可减少生产问题并避免将时间花在浪费性的开发活动上。左移的测试方法的原理是,更早地发现错误意味着可以更快、更容易、更便宜地修复它们。这主要是因为,如果测试被延迟,依赖项变得难以解除。

Shift-left 可以增量地应用于大型和复杂的系统。敏捷通过在敏捷方法中为每个冲刺或迭代使用迷你 v 模型来进一步实现这一点。

编写高质量的需求
定义明确的需求需要正确、完整、分解、明确和逻辑一致。这将有助于避免昂贵的返工和受挫的利益相关者。

为确保完整性,根据实际用例验证需求或按照某些敏捷方法中的建议创建故事很有用。通过分解将需求定义到适当的详细程度也有助于确保低层次的需求集中在单一的概念上。一旦定义了一组需求,最好检查它们的逻辑一致性。使用模板来鼓励语法一致性有助于使这些检查更容易,从而在需求重叠或冲突时变得明显。

从硬件开始 在软件设计过程的早期考虑硬件对于确保不浪费精力至关重要。同样,尽早修复应用程序编程接口 (API) 功能等通信接口也是一个好主意。

在为安全或业务关键型项目选择或设计硬件时,还值得考虑用于测试的硬件可用性的时间范围。当然,最好让选定的硬件可用于测试,但这并不总是可行的,因为有时硬件是并行开发的。在这些情况下,主机然后目标测试可能是一种可行的解决方案,或者在模拟器上进行测试(如果有的话)。当需要在这些不同的环境中执行测试时,可以使用条件编译(例如,#ifdef 等 C 指令),从而避免重复测试的需要。

让领域专家参与需求定义
确保正确的人员正在审查需求并验证它们的正确性和完整性是至关重要的。领域专家的示例包括业务分析师、技术专家、营销和最终用户。从广泛的角度考虑需求有助于从一开始就正确地定义它们。

领域专家应确保指定的需求真正捕捉到应用程序或设备的目标。他们还应该检查需求是否与编写它们要实现的业务、功能和安全目标相匹配。或者,对于较低级别的需求,将它们追溯到满足这些目标之一的较高级别的需求。

为确保优化此流程,不同角色将需要不同级别的需求数据;例如,业务分析师将验证的需求不会分解到与开发人员将验证的需求相同的级别。需求管理工具 (RMT) 可用于确保以清晰和有组织的方式向所有利益相关者提供他们所需的需求数据。将需求保留在 RMT 中还可以通过清楚地显示更高级别和更低级别需求之间的可追溯性来帮助分解。

优化项目范围
在项目的设计阶段,值得注意的是质量和范围的区别。产品的质量是安全或业务关键项目中不能牺牲的东西;但是,可能有缩小范围的空间。大多数安全标准都建议尽可能简单地设计系统,因为这使它们更容易测试,更不用说实施、维护和适应了。

简单的设计
应用程序和固件/硬件之间的内存管理和分层的必要性通常意味着代码复杂性是嵌入式开发中的一个问题。但是,限制使用全局变量和避免嵌套 if 语句(超过两个或三个)等编码实践有助于限制代码复杂性并提高可维护性。MISRA C/C++ 等语言子集可以提供一种有用的方法来提高程序的安全性和可移植性。

确保代码是模块化的有助于防止脆弱的设计,避免具有过长实现的函数,并旨在通过松散耦合使组件具有内聚性。架构分析矩阵是识别组件依赖关系的有用方法,并且可以使用工具来自动生成它们。通过应用分层等技术优化交互也有助于保持嵌入式代码的可管理性。

静态分析
第一个验证阶段很可能是静态分析。此技术可用于在代码执行之前发现代码问题。静态分析工具提供有关代码潜在问题的即时反馈。静态分析解决方案应提供有关影响可靠性、可维护性和可移植性的代码的信息。静态分析还可用于强制执行 MISRA C/C++ 等编码标准。

自动化测试生成
验证的下一阶段是在单元级别动态测试代码并执行检查以确保行为符合需求中的定义。创建这些详细的测试很耗时,但很有必要。现代测试工具可以自动生成这些低级测试。这通常通过解析代码和生成单元测试来实现所需的结构代码覆盖率。

自动生成的测试向量不仅可以驱动代码,还可以检查函数之间传递的参数、可访问的全局数据的值、调用顺序和返回值。此过程还将确保生成一套全面的测试,涵盖已在代码中实现的所有功能。这些生成的测试需要根据软件单元设计需求进行验证,以确保需求得到验证。

使用持续集成
一旦创建了一组通过的测试,它们就可以不断地重新运行,以识别在增强或重构代码时引入的任何回归错误。这个基线安全网减少了对耗时且昂贵的系统测试的依赖,并且更加彻底并准确地识别错误的位置。

持续集成可用于将代码集成到具有自动单元、集成以及系统级测试(如果可能)的共享存储库中。这可以大大加快开发速度,因为每次构建代码时运行回归测试提供了一个非常快速的反馈循环。它还使合并代码分支更容易,从而减少破坏现有代码的机会。

软件开发


图 3:持续集成过程(来源:QA Systems Ltd)

在设置持续集成环境时,重要的是优化运行的测试,以确保您拥有一套全面但精简的测试,这些测试运行速度快,同时仍执行必要的检查。分析代码更改的影响以识别并仅运行受影响的测试有助于优化此过程。自动测试生成也可以是一个好方法,只需单击一个按钮即可创建一套初始的精益回归测试。

保持硬件循环
持续集成的一个目标是持续部署,当涉及到硬件时,这可能很难实现。嵌入式平台上的测试引入了不同于本地主机测试的挑战,例如内存不足、缺乏可用功能(例如文件 I/O)、中断处理以及编程语言的非标准扩展。尽管可以使用变通方法来解决这些问题中的许多问题,但如果可以通过事先计划来避免它们,则效率会更高;例如,通过确保选择具有“内存蠕变”能力的目标并确保硬件有足够的准备来测试软件。

调用控制技术,例如存根(有时称为模拟),是一种标准且有用的方法来管理对不可用对象(例如,硬件)的调用。诸如“包装”之类的高级技术可用于拦截呼叫。这对于集成测试检查返回路径并使用返回值或替换它非常有用。这允许在添加对象时验证对象之间的交互。该技术对于模拟无法实现的现实条件(例如硬件故障)也特别有用。

简化需求可追溯性
所有安全标准都需要测试和需求之间的可追溯性证据。将需求与测试用例匹配的过程很难自动化。对于以自然语言定义的需求,将需求翻译成代码的可靠解释水平仍然远远超出当前机器学习 (ML) 的水平。但是,可以使用一些工具来提高记录需求可追溯性的手动过程的效率。

需求可追溯性经常出现的一个问题是对不断变化的需求的管理。在这里,使用工具来突出显示更改以及与修改后的需求相关的测试用例是非常宝贵的。

编写易于
维护的测试 在重构代码时维护测试也是一个重大问题,因为即使是很小的更改也会破坏测试。单元和集成测试非常依赖源代码结构,因此在更改代码时它可能很脆弱(在某些情况下甚至没有构建),并且修复它们可能很耗时。在这里,测试工具可用于识别影响测试的代码更改和自动化测试维护,包括根据对代码所做的更改提供测试的自动重构。

明智地投资
通过以适合您项目的方式选择上述技术的组合,优化您的开发过程是可行的,即使在质量上不可能妥协。但是,所有优化都需要一定程度的投资,这可能涉及开发新流程、改进工具或增加开发团队的规模。

可以有效地开发安全或业务关键型软件,当然也不能幸免于现代开发技术。只需要更多的知识和努力来确保以不牺牲质量的方式使用工具和技术。

QA Systems是欧洲领先的安全关键市场软件质量解决方案提供商。我们的工具用于自动化单元测试、代码覆盖、集成测试和静态分析。所有工具均由 SGS TüV 独立认证,可用于所有主要安全标准(ISO 26262、IEC 61508、IEC 62304、EN 50128 和 IEC 60880)的安全相关软件开发的最高完整性级别,并且符合 DO 等标准-178B/C。QA Systems 最近在马萨诸塞州波士顿开设了第一家北美办事处,以更好地帮助北美客户加速开发符合安全标准的关键业务软件。

审核编辑 黄昊宇

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分