作者长期从事无人机飞控软件和机器人软件开发，对PX4和双足机器人软件架构尤为熟悉，从菜鸟逐渐了解软件工程、机载软件开发标准等行业规范，在此记录一下，总结工作经验，分享知识，有错误之处请指正。
1. 机载软件概述
机载软件对于飞机和系统的重要性越来越高，机载软件的安全性也成为飞机安全的重要方面。但机载软件有其特殊性，无法像飞机的电缆、蒙皮、面板等一样进行检查和测试，也不可能进行详尽的测试。因此，软件的安全性通常需要通过严格、规范的软件开发流程来保证。
2. 标准简介
2.1 DO178C
机载软件设计离不开DO178C标准，如果没看过可以仔细看《安全关键软件开发与认证-DO-178C标准实践指南》这本书，里面介绍的很详细。
DO-178C（机载系统和设备认证中的软件注意事项）是 FAA、EASA 和加拿大交通部等认证机构用于批准所有基于商业软件的航空航天系统的主要文件。该文件由 RTCA, Incorporated 与 EUROC 联合发布，取代了 DO-178B。新文件称为 DO-178C/ED-12C，于 2011 年 11 月完成，并于 2011 年 12 月获得 RTCA 批准。它于 2012 年 1 月开始销售和使用。
DO-178 要求认证工件之间有记录的双向连接（称为跟踪）。例如，低级需求 (LLR) 可追溯到它所满足的高级需求 (HLR)，还可追溯到用于实现它的源代码行、用于验证源代码相对于需求的正确性的测试用例、这些测试的结果等。然后使用可追溯性分析来确保源代码满足每个需求，每个功能需求都通过测试进行验证，每行源代码都有用途（与需求相关）等。可追溯性分析可评估系统的完整性。认证工件的严谨性和细节与软件级别有关。
3.实践总结
根据作者从事机载软件开发的经验，初学者可以参考下面的流程进行软件开发。
3.1 要求
在实际项目中，需求发现是一个可深可浅的工作。对于没有接触过需求这个概念的人来说，可能只知道这个词的表面意思软件设计阶段产生的文档，就是知道客户想要什么。系统地做完之后，你会发现这是一个广阔的世界。
需求工程的作用可以用一句话来概括：收集客户想要做什么，并最终确定实际做什么。
软件需求包括：高层需求、低层需求、派生需求。
对于一个应用软件的开发来说，需求工程结果的质量很大程度上影响着软件的设计结果，是决定成败的主要环节。充分地获取、记录、分析和确认来自客户的需求，并正确地传递给后续工程是需求分析人员必备的能力。需求工程分析结果形成的需求规范，不仅是后续设计开发的依据，也是客户对已完成系统进行评估和验收的依据。
另一方面，需求工程的内容也极大地影响着软件开发的成本、技术、周期、资源、质量以及最终客户的满意度，需求工程的结果不仅会影响客户最终获得的效果，而且会影响软件开发者的最终利益。
记得看过一个案例，一个项目经理接到一个大公司的ERP工程开发项目。众所周知，ERP项目是庞大的软件项目，对方给的钱不多，但要求的名义功能却五花八门，周期又短。项目经理手下的员工暗自抱怨，觉得这个项目就是个坑。项目经理并没有立刻展开工作，居然天天招待对方老板和项目相关的人，在醉酒的状态下度过了两个月，没有做任何正经工作。当项目员工感觉坚持不下去的时候，负责人终于亮出了底牌，在和对方老板接触的过程中，得知老板真正想做的是把某一项功能做得更完美，而不是把所有事情都做到完美。于是，他花了半年时间专心开发实现某一项功能，其他功能就平平无奇了。验收的时候，对方老板很满意。
这个案例让笔者非常震撼，在项目对接中，对方提到了一些真实的需求，也提到了一些想象中的需求，看似需求很多，但现实中的痛点可能只有一个。抓住痛点去满足它，而不是一下子抓住所有，才是满足需求的核心。这也是毛主席说的抓住主要矛盾。
另一方面，用户可能提10个需求，都是痛点，这时候你还是需要跟甲方沟通，如何优先处理这些需求。
这些是项目级需求提取。
具体到机载软件开发的飞控软件开发，根据DO178的描述，飞控软件作为飞行控制系统的软件实现，需要体现飞行器系统对飞控系统的要求。另一方面，飞行控制系统的安全关键特性决定了飞控软件的安全关键等级，从而决定了软件工程过程中需求、设计、开发、测试等一系列活动的标准。这些标准对活动提出了要求。
根据项目规模大小，适用规范可以进行量身定制、简化和专门化，以适应项目的实际需求。杀鸡不需要屠刀，杀牛也不需要鸡刀。团队规模较小时，不需要做复杂的流程管理，文档也不需要太详细。当团队专业方向齐全、成员较多时，组织本身的发展也需要合理的流程管理、规范的文档和代码规范。
3.2 设计
预期软件模块的描述
设计的作用是作为软件实施阶段的蓝图。设计描述了软件如何组合在一起（架构）以及如何执行预期功能。
好的设计具有以下特点：
抽象性、模块化、强内聚、低耦合、信息隐藏、低复杂度、良好的软件设计特点、可重复的方法、强维护性、健壮性、文档化、可评审、易于测试、避免不必要的特性。
添加新功能后，为避免对旧功能造成复杂的影响，所有影响都必须进行回归测试。
3.3 发展
实现软件框架和模块
使用良好的设计技术
鼓励良好的编程实践
执行代码审查
提供优秀的代码示例
遵守编码标准
3.3.1 软件配置管理
配置管理是识别、组织和控制编程团队正在构建的软件变更的艺术，其目标是通过最小化错误来最大程度地提高生产率。它不仅适用于源代码，所有软件生命周期材料都需要它。用于构建、验证和证明软件合规性的所有数据和文档也需要一定程度的配置管理。应用 SCM 的严格程度取决于软件的级别和工件的特性。
配置管理的目标
1.配置项被识别；
2.建立基线和可追溯性；
3、建立问题报告、变更控制、变更评审、以及配置状态记录；
4.建立档案、摘录并发布；
5.建立软件加载控制；
6.建立软件生命周期环境控制；
3.4 测试
飞控系统试验在整个V型研发过程中起着至关重要的作用，在大型载人飞机飞控系统研制中，飞控系统试验研制费用占系统总研制费用的34%。
3.4.1 软件测试
测试软件功能和性能
测试是对系统或系统组件进行验证以验证其是否满足指定要求并检测错误。
测试措施：
1.单独的测试模块代码；
2.模拟测试；
3.将结果数据打印成图表，以供核对；
4.代码交叉审查；
5.交叉运行模拟试验；
3.4.2 模拟测试
一般包括软件在环仿真、硬件在环仿真等，仿真的目的是验证软件功能是否正常、控制性能是否符合标准。
3.4.3 地面测试
模拟试验完成后，进行机上地面试验，测试螺旋桨转动、舵机偏转等是否正常。
地面测试包括铁鸟测试。
3.4.4 飞行测试
准备不同的测试对象软件设计阶段产生的文档，一般从低风险到高风险逐一进行测试。
测试时不出意外的小故障，会让人很开心，因为不会造成大的损失。测试流程要设计好，每个子项要逐一测试，避免没有把握就直接进入全面测试。如果出现重大意外，会极大影响测试进程，甚至项目被砍。
