嵌入式软件可靠性设计规范方案汇总17845.pdf
.嵌入式软件可靠性设计规范汇总 序号 分类 规范要求 1.人机交互设计 界面分成两类,操作控制类信息、测量监控类信息.每类又分成三级,高优先级、中优先级、低优先级.不同类型的信息内容要分区,不同级别的信息放置位置不同、大小不同、色彩不同.2.信息内容直观,不必经过换算 3.安全关键操作需经过再次确认 4.色彩只有两个主色调,其他只能做点缀色 5.从任何界面下进入到其他的界面下,最多不得超过 3 层 6.单一操作功能下的界面用滚屏方式实现,不能用翻页形式实现 7.同一界面下的数据不要比对 8.用通栏布局代替多栏布局 9.整合相似的功能,去掉零碎的 UI 元素 10.主要功能需要多次强化显示 11.区分选中和可点击的状态,不要使用户困惑 12.布局有层次有重点,而非简单罗列 13.允许用户撤销操作而不是使用弹窗需要用户确认 14.页面上多使用对比的方法 15.使用简洁的表单 16.把选项列出来而不是藏起来 17.使用连续性的提示符,别让用户误以为页面到了终点 18.功能专一而不是使用太多的链接 19.提示执行结果的状态 20.用直接操作来代替无数个菜单 21.直接显示输入框可以省略一个页面 22.试着减少线框,减少不必要的注意 23.用户没有使用记录的时候要善于引导 24.给出默认的选项而不需要用户选择.25.保持一致性降低用户的学习成本 26.自动补全一些数据,降低用户的操作负担 27.尊重用户的使用习惯而不是创造新的规则 28.将相关的条目分组,不要杂乱无章的排列 29.采用及时校验而不是到最后才提示错误 30.需要用户输入的格式宽松严格限定格式 31.可以给用户提供一些快捷操作 32.使用一些对比 33.初始化的时候给用户一些激励 34.循序渐进地引导用户,不要简单粗暴地直接呈现给用户 35.编译器 项目主管检查团队成员编译器版本是否统一 36.软件工程师项目开始前,检查自己所用编译器版本与团队是否一致 37.编译器环境在项目开发结束时,一并提交归档；38.任何一个新设计的软件系统中、任何一个新的变量类型,均须做强制定义,以避免程序移植中可能产生的数据类型默认规格不一致而导致错误的问题 39.多人开发必须统一版本、补丁,必须有配置说明,安装指南；40.所有变量使用前必须赋初值；41.Alarm设计 所有报警要分级,并在设计开发文档中予以说明.包括：每一个报警的定义、触发的条件、触发时人与设备的距离和人的状态、报警所允许的处理时间、报警的优先级别 界面上报警提示的位置及图标方式 42.从报警事件发生开始、到报警触发、到被人感知到、到系统自动处理或人工处理并生效、直至问题被排除的间隔时间,需进行测量并确认.43.高级报警显示：红色,1.4Hz 2.8Hz,信占比率 20%60%开 44.中级报警显示：黄色,0.4Hz 0.8Hz,信占比率 20%60%开 45.低级报警显示：蓝绿色或者黄色,常开,信占比率 100%46.高优先级和中优先级的报警上下限设置值一旦超出可能引起较严重后果的非合理报警数值区域时,均需加单独的对话弹出框予以提醒操作者 47.默认的报警预置不允许修改,并提供让用户能恢复到出厂默认报警设置的操作途径 48.做报警日志记录,为以后的故障分析、维修检查或商业纠纷提供依据 49.与硬件接口的软件 数据传输接口的硬件性能限制了数据传输速率的提高,在确定波特率前,要确认硬件所能承受的最高传输率,光耦、485、232、CAN、传输线上有防护器件的端口 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.全局变量慎用,不得不用时,要专门组织项目组讨论会,集体确定是否有必要；设计时用统一的操作函数对其进行操作.72.计算中用到的所有数据必须做值域范围的有效性判断,如读取 EEPROM 中的数据、调用函数的返回值、运算的中间值、IO 口的数据、寄存器的数据 73.系统架构按照控制层和应用层二分法合理分层；控制层的模块划分以受控对象唯一为判定标准、应用层以操作动作唯一为判定标准 74.相同的控制对象在程序中只出现一次,相同的信息只出现一次 75.变量和函数要有统一命名规范 76.功能模块的形参个数越少越好、数据类型越简单越好,以保证低耦合；最好控制在 3 个以.内 77.确定模块间的耦合方式为哪一种,如果处于非优选的耦合方式,要分析是否可能按照较优先推荐的耦合方式进行耦合.排序优选顺序：直接数据耦合-间接数据耦合-控制耦合-外部数据耦合-公共数据耦合 78.设计更改时,接口必须向前兼容；设计更改审核需作为重点检查项,尤其注意对硬件的读写访问协议 79.以安全性内核的架构形式进行主体架构设计,并将以下5类重要模块打包进安全性内核中,加强管理：a 故障检测的优先级结构及安全性控制或校正逻辑、处理和响应故障的模块；b 中断处理程序、中断优先级模式及允许或禁止中断的例行程序 c 产生对硬件进行自主控制信号的软件 d 产生直接影响硬件部件运动或启动安全关键功能的信号的软件 e 其输出是显示安全关键硬件的状态的软件.80.禁止使用空间不受控如循环到、时间不受控如循环到的语句 81.工作时间不超过 1/2 时启动休眠 82.防跑飞的软件陷阱 83.变 量/存储 变量名称里加入数据类型和作用域的信息,使隐含信息显性化,避免可读性差和数据类型强制转换的问题 84.重要数据备份需采用异地备份方式,异地存储的介质、面对的应力不是同一类应力,避免单一事故造成的数据丢失 85.重要数据之前之后预留较大的空闲存储区,避免被之前数据覆盖；比如占 2 字节的变量分配 4 bytes 86.禁止使用一位、00H、FFH、互补、在二进制码中仅差 1-2 位的弱数据类型来表示状态含义 87.块存储 88.重复刷新 89.故障就地解决 分级.非对称操作和状态 提示与反馈 简单与复杂
