嵌入式软件可靠性设计规范汇总汇编.docxVIP

嵌入式软件可靠性设计规范汇总序号分类规范要求人机交互设计界面分成两类，操作控制类信息、测量监控类信息。每类又分成三级，高优先级、中优先级、低优先级。不同类型的信息内容要分区，不同级别的信息放置位置不同、大小不同、色彩不同。信息内容直观，不必经过换算安全关键操作需经过再次确认色彩只有两个主色调（一前景色，一背景色色），其他只能做点缀色从任何界面下进入到其他的界面下，最多不得超过3层单一操作功能下的界面用滚屏方式实现，不能用翻页形式实现同一界面下的数据不要比对用通栏布局代替多栏布局整合相似的功能，去掉零碎的UI元素主要功能需要多次强化显示区分选中和可点击的状态，不要使用户困惑布局有层次有重点，而非简单罗列允许用户撤销操作而不是使用弹窗需要用户确认页面上多使用对比的方法使用简洁的表单把选项列出来而不是藏起来使用连续性的提示符，别让用户误以为页面到了终点功能专一而不是使用太多的链接提示执行结果的状态用直接操作来代替无数个菜单直接显示输入框可以省略一个页面试着减少线框，减少不必要的注意用户没有使用记录的时候要善于引导给出默认的选项而不需要用户选择保持一致性降低用户的学习成本自动补全一些数据，降低用户的操作负担尊重用户的使用习惯而不是创造新的规则将相关的条目分组，不要杂乱无章的排列采用及时校验而不是到最后才提示错误需要用户输入的格式宽松严格限定格式可以给用户提供一些快捷操作使用一些对比初始化的时候给用户一些激励循序渐进地引导用户，不要简单粗暴地直接呈现给用户编译器项目主管检查团队成员编译器版本是否统一（对外协团队、及复用以前的成熟代码时，尤其关注此项）软件工程师项目开始前，检查自己所用编译器版本与团队是否一致（对外协团队、及复用以前的成熟代码时，尤其关注此项）编译器环境在项目开发结束时，一并提交归档；任何一个新设计的软件系统中、任何一个新的变量类型，均须做强制定义，以避免程序移植中可能产生的数据类型默认规格不一致而导致错误的问题（定义时不能直接使用基本类型，必须转型，建立跨平台适配库；）多人开发必须统一版本、补丁，必须有配置说明，安装指南；所有变量使用前必须赋初值；Alarm设计所有报警要分级（高、中、低），并在设计开发文档中予以说明。包括：每一个报警的定义、触发的条件、触发时人与设备的距离和人的状态、报警所允许的处理时间、报警的优先级别界面上报警提示的位置及图标方式从报警事件发生开始、到报警触发、到被人感知到、到系统自动处理或人工处理并生效、直至问题被排除的间隔时间，需进行测量并确认高级报警显示：红色，1.4Hz ～ 2.8Hz，信占比率20% ～ 60% 开中级报警显示：黄色， 0.4Hz ～ 0.8Hz，信占比率20% ～ 60% 开低级报警显示：蓝绿色或者黄色，常开，信占比率100%高优先级和中优先级的报警上下限设置值一旦超出可能引起较严重后果的非合理报警数值区域时，均需加单独的对话弹出框予以提醒操作者默认的报警预置不允许修改，并提供让用户能恢复到出厂默认报警设置的操作途径做报警日志记录，为以后的故障分析、维修检查或商业纠纷提供依据与硬件接口的软件数据传输接口的硬件性能限制了数据传输速率的提高，在确定波特率前，要确认硬件所能承受的最高传输率，光耦、485、232、CAN、传输线上有防护器件（TVS或压敏电阻）的端口硬件端口读进来的数据必须加值域范围的判断硬件端口读取数据，必须加可控时间或次数的有限次限制A/D 的位数比前端放大电路的精度要求略高即可，并通过数学计算验证对运动部件的控制，正向运动突然转向反向运动时，必须控制先正向减速到0，然后再反向加速的控制方式运动部件停机后、再快速启动的工作控制方式是不允许的。须停机、开机、delay延时、再启动执行机构，以确保执行机构先释放原来运动状态的惯性，然后再从静态下启动运动部件都有过渡过程特性，软件驱动时的上升沿和下降沿的过渡特性会直接影响到硬件的安全和执行效果板卡启动时，先initMCU、然后Delay、然后initIO，以确保各芯片的上电电源都已经稳定下来再启动工作对采集自有可能受到干扰的模拟端口输入的数字量数据，一定要加上下限、Δ/Δt、规律性干扰的滤波措施三个方面的容错性机制对数字端口传输数据可以连续传输两遍，以防范随机性偶发干扰，实时性要求较高的，可以连续传三遍，2：1判定模块之间的数据通信联络，用周期性读取的方式、或请求-应答的方式传送数据，一旦超出周期性时间要求，或未应答，则判定硬件失效，需有软件的配套措施。如对接口芯片复位、报警提示、调用默认安全数据临时顶替…定时刷屏，定时刷Register,防止干扰导致的屏幕花屏、register数据丢失或篡改若系统内部既有干扰源，又有敏感电路部分，对这两部分软件控制操作之间加delay。如电机或继电器启动或停止时，采用motor_on