嵌入式软件可靠性设计规范checklist
电子系统可靠性设计-嵌入式系统软件的可靠性设计PPT课件【2024版】
嵌入式系统软件的可靠性设计 电子系统可靠性设计
2）控制要求或处理要求
嵌入式系统对实时性要求较高
工作顺序要求严格：发送数据的时间、接收数据的时间、 时序关系、CPU和外设的同步 3）可靠性问题
对软件的可靠性要求和出错处理的要求
确定出错处理方案，列出各种错误图像、显示错误的 方法 用户的需求：全面详细的了解，设计者的理解和用户的解 释必须完全一致，形成文档
5、性能错误
电子系统可靠性设计
指设计的软件性能和用户的需求相差太大，不能满足用 户的要求
例如：软件的响应时间、执行时间、控制系统的精度等
例如：
计算机的语音识别，尽管识别率满足要求，但是识别 时间不能太长，如果需要几分钟进行识别，无法应用
嵌入式系统发生故障时：
需要立即做出响应，自动保护和报警
如果响应时间过长：会发生严重的后果
依赖于设计者的思路、方法 在软件开发的每一步：都可能引入故障 每一个阶段都要采取质量控制手段
实现软件的可靠性要求 一、软件工程的开发模式 二、嵌入式系统的软件开发 三、软件可靠性管理
嵌入式系统软件的可靠性设计 电子系统可靠性设计
一、软件工程的开发模式 1、瀑布式开发模型 2、原型法开发模型 3、螺旋形开发模式 4、面向对象的软件开发模型
上个例子:
故障率λ=0.004
平均故障间隔时间MTBF =1/λ =250
嵌入式系统软件的可靠性设计 电子系统可靠性设计
嵌入式系统软件的可靠性设计 电子系统可靠性设计
嵌入式系统软件的可靠性设计
2、方案中有错误
电子系统可靠性设计
当用户需求充分了解后，进行软件的总体方案设计
2 嵌入式软件可靠性设计规范 (1)
嵌入式软件可靠性设计规范0、概述 (3)1、定义 (3)1.1、定义 (3)1.2、说明 (3)2、计算机系统设计 (3)2.1、一般要求 (3)2.2、硬件与软件功能的分配原则 (4)2.3、硬件与软件可靠性指标的分配原则 (4)2.4、安全关键功能的人工确认 (4)2.5、安全性内核 (4)2.6、自动记录系统故障 (4)2.7、禁止回避检测出的不安全状态 (5)2.8、保密性设计 (5)2.9、容错设计 (5)2.10、安全关键软件的标识原则 (5)3、硬件设计 (5)3.1、硬件选用 (5)3.2、总线检测 (5)3.3、加电检测 (6)3.4、电源失效的安全措施 (6)3.5、主控计算机失效的安全措施 (6)3.6、反馈回路传感器失效的防护措施 (6)3.7、电磁干扰的防护措施 (6)3.8、维修互锁措施 (6)4、软件需求分析 (6)5、软件危险分析 (7)6、安全关键功能的设计 (7)7、冗余设计 (7)7.1、指令冗余设计 (7)7.2、软件陷阱与软件拦截技术 (7)7.3、软件冗余 (9)8、接口设计 (10)8.1、硬件接口要求 (10)8.2、硬件接口的软件设计 (10)8.3、人机界面设计 (10)8.4、报警设计 (10)8.5、软件接口设计 (11)9、软件健壮性设计 (11)9.1、电源失效防护 (11)9.2、加电检测 (11)9.3、电磁干扰 (11)9.4、系统不稳定 (12)9.5、接口故障 (12)9.6、干扰信号 (12)9.7、错误操作 (12)9.8、监控定时器的设计 (12)9.9、异常保护设计 (12)10、简化设计 (13)10.1、单入和单出 (13)10.2、模块的独立性 (13)10.3、模块的扇入扇出 (13)10.4、模块耦合方式 (13)10.5、模块内聚顺方式 (13)10.6、其他特殊考虑 (14)11、余量设计 (14)11.1、资源分配及余量要求 (14)11.2、时序安排的余量要求 (14)12、数据要求 (14)12.1、数据需求 (14)12.2、属性控制 (14)12.3、数值运算范围控制 (15)12.4、合理性检查 (15)13、防错程序设计 (15)13.1、参数化 (15)13.2、公用数据和公共变量 (15)13.3、标志 (15)13.4、文件 (15)13.5、非授权存取的限制 (16)13.6、无意指令跳转的处理 (16)13.7、程序检测点的设置 (16)13.8、寻址模式的选用 (16)13.9、数据区隔离 (16)13.10、安全关键信息的要求 (16)13.11、信息存储要求 (17)13.12、算法选择要求 (17)14、编程要求 (17)14.1、语言要求 (17)14.2、汇编语言编程限制 (17)14.3、高级语言的编程限制 (17)14.4、圈复杂度指数（McCabe） (17)14.5、软件单元的规模 (18)14.6、命名要求 (18)14.7、程序格式要求 (18)14.8、程序注释要求与方法 (18)14.8.1、注释的一般要求 (18)14.8.2、模块头注释要求 (19)14.8.3、模块内注释要求 (19)14.8.4、安全关键内容注释要求 (19)14.9程序设计风格 (19)14.9.1、通用类 (19)14.9.2、结构类 (20)14.9.3、说明类 (20)14.9.4、输人输出类 (21)14.9.5、语言类 (21)15、多余物的处理 (21)15.1、文档中未记载特征的清除 (21)15.2、程序多余物的清除 (21)15.3、未使用内存的处理 (21)15.4、覆盖的处理 (22)16、软件更改要求 (22)17、嵌入式软件测试 (22)17.1、需求遗漏或不明确 (22)17.2、配置保存的生效 (22)17.3、缺省配置的影响 (23)17.4、报警和清除 (23)17.5、菜单选项测试 (23)17.6、缺省配置测试 (23)17.7、系统测试注意事项 (23)附录1：推荐的软件安全关键程度分级 (23)附录2：软件开发各阶段的适用准则和要求 (24)0、概述嵌入式软件是电子系统的重要组成部分，它具有不同于硬件系统的可靠性特征和可靠性设计方法。
软件编程规范总则CHECKLIST
号
总则条款
执行情况
说明
1排版
1
¹1-1：程序块要采用缩进风格编写，缩进的空格
数为4个。
是[]否[]免[]
2
¹1-2：相对独立的程序块之间、变量说明之后必
须加空行。
是[]否[]免[]
3
¹1-3：较长的语句（>80字符）要分成多行书写，
长表达式要在低优先级操作符处划分新行，操
作符放在新行之首，划分出的新行要进行适当
是[]否[]免[]
¹8-5：循环体内工作量最小化。
是[]否[]免[]
9质量保证
¹9-1：在软件设计过程中构筑软件质量。
是[]否[]免[]
¹9-2：代码质量保证优先原则
是[]否[]免[]
¹9-3：只引用属于自己的存贮空间。
是[]否[]免[]
¹9-4：防止引用已经释放的内存空间。
是[]否[]免[]
¹9-5：过程/函数中分配的内存，在过程/函数退
case语句前加上明确的注释。
是[]否[]免[]
3标识符命名
¹3-1：标识符的命名要清晰、明了，有明确含义，
同时使用完整的单词或大家基本可以理解的缩
写，避免使人产生误解。
是[]否[]免[]
¹3-2：命名中若使用特殊约定或缩写，则要有注
释说明。
是[]否[]免[]
¹3-3：自己特有的命名风格，要自始至终保持一
在调测时有可能发生的非法情况。
是[]否[]免[]
¹7-7：不能用断言来检查最终产品肯定会出现且
必须处理的错误情况。
是[]否[]免[]
¹7-8：对较复杂的断言加上明确的注释。
是[]否[]免[]
¹7-9：用断言确认函数的参数。
嵌入式软件可靠性
2006.9.21
不同的嵌入式系统对其安全可靠性的要求是不一 样的。一般说来，嵌入式系统对可靠性与安全性 的要求要高于非嵌入式系统。对于PC机，偶然死 机需要用户重新启动，损失有限，而对于嵌入式 控制系统，死机是绝对不允许的。 系统的安全可靠性包含两重含义：一个是强调其 安全性，特别是安全紧要系统(Safetycritical)，即 与人性命攸关的系，保证安全是第一位的；另一 重意思是计算方法要科学，结果要准确可靠，不 得有误。
ቤተ መጻሕፍቲ ባይዱ
保证嵌入式软件的安全性，除了在整个软件开发过程中要边开发、边自我检查、测 试之外，对于安全紧要系统，需要有专门的程序测试人员，甚至一支与开发队伍并 列的测试队伍来保证代码的安全性。
嵌入式信息系统可用性检查列表的设计
嵌入式信息系统可用性检查列表的设计余铮在以嵌入式和网络技术为代表的全息技术不断创新的过程中，人们的生存环境也发生了一定的变化。
因特网技术改变了人们的管理及通信方式，以嵌入式系统为基础的信息技术[本文来自于]在工程设计、通信系统、军事武器等行业中被广泛应用，物联网技术能够实现人们智能化的对世界和自身的生活环境进行感知。
现代社会的应用需求都是设备能够实现信息化和网络化，从而要求计算资源及物理资源相互结合，实现下一代智能系统的开发。
但是根据系统设计和相关的任务特点，要想实现现代嵌入式信息系统的可用性评估，就要通过可用性列表进行。
基于此，本文就针对嵌入式信息系统可用性检查列表的设计进行分析。
【关键词】嵌入式信息系统可用性检查列表嵌入式信息系統是现代社会行业中尤为重要的态势感知手段，能够在正确的时间和地点传达正确的信息，从而提高相应决策的正确性，有效实现正确信息的传递和正确结果的获得。
但是，信息具有不完整性、多变性和确定性，阻碍了信息系统作用的发挥。
在此背景下，嵌入式信息系统的可用性就尤为重要。
系统的可用性较高，那么就能够有效降低用户在工作过程中的负荷，避免出现多种人为失误，提高用户满意度。
所以，在现代嵌入式信息系统设计过程中，进行以用户为基础的设计，提高系统可用性备受人们关注。
1 嵌入式信息系统可用性检查列表的设计方式本文设计的可用性检查列表的主要目的就是找到系统中的内在问题，提出以可用性问题框架为基础的结构，创建面向系统的可用性评价准则，从而实现嵌入式信息系统可用性检查列表，主要步骤为：首先，创建以UPT框架为基础的信息系统可用性结构，将可用性问题分为两个层面，分别为设计层面及任务层面，比起其他的分类基础，这种方法能够以用户为中心对问题进行全面的考虑。
根据现代信息系统的特点，实现UPT的调整，将产品设计分为软件界面和物理硬件两个部分进行设计，然后以此为基础创建子结构，主要包括三类内容，详见图1。
通过图1可以看出来，信息系统设计中的可用性问题主要利用静态检索实现，任务层面的可用性问题主要利用动态检索表示。
嵌入式软件可靠性设计三方面的考虑：防错,判错,容错的详细概述
嵌入式软件可靠性设计三方面的考虑：防错,判错，容错的详细概述0.前言设备的可靠性涉及多个方面：稳定的硬件、优秀的软件架构、严格的测试以及市场和时间的检验等等。
这里着重谈一下作者自己对嵌入式软件可靠性设计的一些理解，通过一定的技巧和方法提高软件可靠性。
这里所说的嵌入式设备,是指使用单片机、ARM7、Cortex-M0，M3之类为核心的测控或工控系统。
嵌入式软件可靠性设计应该从防错、判错和容错三方面进行考虑. 此外,还需理解自己所使用的编译器特性。
1.防错良好的软件架构、清晰的代码结构、掌握硬件、深入理解C语言是防错的要点，这里只谈一下C语言。
“人的思维和经验积累对软件可靠性有很大影响"。
C语言诡异且有种种陷阱和缺陷，需要程序员多年历练才能达到较为完善的地步。
“软件的质量是由程序员的质量以及他们相互之间的协作决定的”。
因此，作者认为防错的重点是要考虑人的因素。
“深入一门语言编程，不要浮于表面”。
软件的可靠性，与你理解的语言深度密切相关，嵌入式C更是如此。
除了语言，作者认为嵌入式开发还必须深入理解编译器。
本节将对C语言的陷阱和缺陷做初步探讨。
1.1 处处皆陷阱最初开始编程时，除了英文标点被误写成中文标点外，可能被大家普遍遇到的是将比较运算符==误写成赋值运算符=，代码如下所示：if(x=5) { …}这里本意是比较变量x是否等于常量5，但是误将’==’写成了’=’，if语句恒为真。
如果在逻辑判断表达式中出现赋值运算符，现在的大多数编译器会给出警告信息。
并非所有程序员都会注意到这类警告，因此有经验的程序员使用下面的代码来避免此类错误：if(5==x) { …}。
嵌入式软件可靠性设计规范方案
嵌入式软件可靠性设计规范方案引言：嵌入式软件是嵌入在设备中的特定用途软件，其可靠性对设备的正确运行和用户的安全至关重要。
为了确保嵌入式软件的可靠性，需要设计一套规范方案，本文将从软件需求、架构设计、编码实现和测试验证等方面进行详细讨论。
一、软件需求规范1.明确定义软件的功能和性能需求，包括输入、输出、算法、响应时间等。
2.定义软件的安全要求，确保系统在可能的风险下能正确响应和保证用户的安全。
3.制定软件的兼容性要求，确保软件与硬件的适配性以及其他相关软件的兼容性。
4.设定软件的可靠性指标，明确软件的容错、可恢复性和可靠性要求。
二、架构设计规范1.使用模块化设计方法，将软件拆分为功能独立的模块，每个模块负责实现一个特定的功能。
2.定义明确的模块接口，确保模块之间的数据传递和信息交换正确可靠。
3.设计预防和处理异常的机制，如输入校验和错误处理，确保系统在异常情况下仍能正常运行和恢复。
4.进行合理的资源管理，包括内存、处理器、外部设备等，确保系统资源的高效利用和稳定性。
三、编码实现规范1.使用结构化的编程方法，遵循良好的编码习惯，如良好的变量命名、代码缩进等。
2.采用清晰易读的代码风格，注释详细，增加代码的可读性和可维护性。
3.进行严格的代码审查，发现和纠正潜在的错误和缺陷。
4.使用合适的算法和数据结构，确保软件的效率和正确性。
四、测试验证规范1.设计全面的测试用例，覆盖软件的各个功能和边界条件。
2.进行单元测试，验证各个模块的正确性和可靠性。
3.进行集成测试，确保各个模块协同工作的正确性和稳定性。
4.进行系统测试，测试整个系统的功能、性能和可靠性。
五、软件配置管理规范1.确定软件的版本控制策略，如使用版本号管理和追踪软件的版本变更。
2.建立有效的配置管理系统，确保软件配置的可控性和可追溯性。
3.设定软件发布和部署策略，确保软件的正确发布和部署。
六、软件维护规范1.定期审查和更新软件的文档，包括需求文档、设计文档和测试文档等。
必须收藏：原理图设计规范126条checklist
必须收藏：原理图设计规范126条checklist类别描述检视规则原理图需要进行检视，提交集体检视是需要完成自检，确保没有低级问题。
检视规则原理图要和公司团队和可以邀请的专家一起进行检视。
检视规则第一次原理图发出进行集体检视后所有的修改点都需要进行记录。
检视规则正式版本的原理图在投板前需要经过经理的审判。
差分网络原理图中差分线的网络，芯片管脚处的P和N与网络命令的P 和N应该一一对应。
单网络原理图中所有单网络需要做一一确认。
空网络原理图中所有空网络需要做一一确认。
网格1、原理图绘制中要确认网格设置是否一致。
2、原理图中没有网格最小值设置不一致造成网络未连接的情况。
网络属性确认网络是全局属性还是本地属性封装库1、原理图中器件的封装与手册一致。
2、原理图器件是否是标准库的symbol。
绘制要求原理图中器件的封装与手册一致。
指示灯设计默认由电源点亮的指示灯和由MCU点灭的指示灯，便于故障时直观判断电源问题还是MCU问题网口连接器确认网口连接器的开口方向、是否带指示灯以及是否带PoE 网口变压器确认变压器选型是否满足需求，比如带PoE按键确认按键型号是直按键还是侧按键电阻上下拉同一网络避免重复上拉或者下拉OD门芯片的OD门或者OC门的输出管脚需要上拉匹配高速信号的始端和末端需要预留串阻三极管三极管电路需要考虑通流能力可测试性在单板的关键电路和芯片附近增加地孔，便于测试连接器防呆连接器选型时需要选择有防呆设计的型号仿真低速时钟信号，一驱动总线接口下挂器件的驱动能力、匹配方式、接口时序必须经过仿真确认，例如MDC/MDIO、IIC、PCI、Local bus仿真电路中使用电感、电容使用合适Q值，可以通过仿真。
时序确认上电时序是否满足芯片手册和推荐电路要求。
时序确认下电时序是否满足芯片手册和推荐电路要求。
时序确认复位时序是否满足芯片手册和推荐电路要求。
复位开关单板按键开关设计，要防止长按按键，单板挂死问题，建议按键开关设计只产生一段短脉宽低电平。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
嵌入式软件可靠性设计规范汇总
43.高级报警显示：红色，1.4Hz～ 2.8Hz，信占比率20%～60%开
44.中级报警显示：黄色，0.4Hz～0.8Hz，信占比率20%～60%开
45.低级报警显示：蓝绿色或者黄色，常开，信占比率100%
46.
高优先级和中优先级的报警上、下限设置值，一旦超出可能引起较严重后果的非合理报警数值区域时，均需加单独的对话弹出框予以提醒操作者
47.
默认的报警预置不允许修改，并提供让用户能恢复到出厂默认报警设置的操作途径
48.做报警日志记录，为以后的故障分析、维修检查或商业纠纷提供依据
与硬件接口的软件49.
数据传输接口的硬件性能限制了数据传输速率的提高，在确定波特率前，要确认硬件所能承受的最高传输率，光耦、485、232、CAN、传输线上有防护
器件（TVS或压敏电阻）的端口
50.硬件端口读进来的数据必须加值域范围的判断
51.硬件端口读取数据，必须加可控时间或次数的有限次限制
52.A/D的位数比前端放大电路的精度要求略高即可，并通过数学计算验证
53.
对运动部件的控制，正向运动突然转向反向运动时，必须控制先正向减速到0，然后再反向加速的控制方式
54.
运动部件停机后、再快速启动的工作控制方式是不允许的。
须停机、开机、delay延时、再启动执行机构，以确保执行机构先释放原来运动状态的惯性，然后再从静态下启动
55.
运动部件都有过渡过程特性，软件驱动时的上升沿和下降沿的过渡特性会
直接影响到硬件的安全和执行效果
56.
板卡启动时，先initMCU、然后Delay、然后initIO，以确保各芯片的上电
电源都已经稳定下来再启动工作
57.
对采集自有可能受到干扰的模拟端口输入的数字量数据，一定要加上、下
限、Δ/Δt、规律性干扰的滤波措施三个方面的容错性机制
58.
对数字端口传输数据可以连续传输两遍，以防范随机性偶发干扰，实时性要求较高的，可以连续传三遍，2：1判定
59.
模块之间的数据通信联络，用周期性读取的方式、或请求-应答的方式传送
数据，一旦超出周期性时间要求，或未应答，则判定硬件失效，需有软件的
配套措施。
如对接口芯片复位、报警提示、调用默认安全数据临时顶替…
60.
定时刷屏，定时刷Register,防止干扰导致的屏幕花屏、register数据丢失或篡改
61.
若系统内部既有干扰源，又有敏感电路部分，对这两部分软件控制操作之间加delay。
如电机或继电器启动或停止时，采用motor_on–delay-AD_start
62.对MCU之外的存储操作，最好加存储后检查，并有成功提示
63.输入信号要做处理：按键、电源等做防抖处理及范围限制
64.1/2以上的机时MCU不必工作时，用睡眠设置抗扰
代码65.
程序代码模块要按照功能分级，基本功能和可能导致安全问题的模块为高
级、用户能感知到但不属于高级功能部分的功能为中级、其他为低级；高中级程序的编制人员、测试、审核、设计更改均须给予特别的重视和资源倾斜
66.控制类函数，单一函数内只能有单一功能和单一的受控对象
67.
代码中，一个语句中，只能用于完成单一的功能，禁用复合语句，对复合型语句用分解的办法化简成多个简单小语句
68.
函数调用时，形参是容易出错的地方，函数编程时，形参注释的字体、颜色、大小较突出为佳；且在函数内部，形参仅做数据传递，不参与运算，在函数内单独定义局部变量，接收形参数据后，用内部变量进行运算
69.
程序中不出现常数（局部循环性常数不在此列），常数用宏定义方式；调试
中才能确定的调节参数常数，宜通过“工程师校准界面”中补偿参数的方式预留用户设置接口，以补偿因环境条件或配套设备参数变化引起的参数变化
量；而非写死在程序中
70.
全局变量慎用，不得不用时，要专门组织项目组讨论会，集体确定是否有必要；设计时用统一的操作函数对其进行操作。
71.
计算中用到的所有数据必须做值域范围的有效性判断，如读取EEPROM中的
数据、调用函数的返回值、运算的中间值、IO口的数据、寄存器的数据…72.
系统架构按照控制层和应用层二分法合理分层；控制层的模块划分以受控对象唯一为判定标准、应用层以操作动作唯一为判定标准
73.相同的控制对象在程序中只出现一次，相同的信息只出现一次
74.变量和函数要有统一命名规范
75.
功能模块的形参个数越少越好、数据类型越简单越好，以保证低耦合；最好控制在3个以内
76.确定模块间的耦合方式为哪一种，如果处于非优选的耦合方式，要分析是否可能按照较优先推荐的耦合方式进行耦合。
排序优选顺序：直接数据耦合-间接数据耦合-控制耦合-外部数据耦合-公共数据耦合
77.
设计更改时，接口必须向前兼容；设计更改审核需作为重点检查项，尤其注意对硬件的读写访问协议
78.以安全性内核的架构形式进行主体架构设计，并将以下5类重要模块打包进安全性内核中，加强管理（测试、设计更改、评审时特殊关注）：a故障检测的优先级结构及安全性控制或校正逻辑、处理和响应故障的模块；
b中断处理程序、中断优先级模式及允许或禁止中断的例行程序
c产生对硬件进行自主控制信号的软件
d产生直接影响硬件部件运动或启动安全关键功能的信号的软件
e其输出是显示安全关键硬件的状态的软件。
79.
禁止使用空间不受控（如循环到Δ<ε，再停止连续步进递增存储）、时间不受控（如循环到Δ<ε，再跳出循环）的语句
变量/存储80.
变量名称里加入数据类型和作用域的信息，使隐含信息显性化，避免可读性差和数据类型强制转换的问题
81.
重要数据备份需采用异地备份方式，异地存储的介质、面对的应力不是同一类应力，避免单一事故造成的数据丢失
82.
重要数据之前之后预留较大的空闲存储区，避免被之前数据覆盖；比如占2字节的变量分配4bytes
83.
禁止使用一位、00H、FFH、互补、在二进制码中仅差1-2位的弱数据类型来表示状态含义。