嵌入式软件可靠性设计规范方案汇总.doc

嵌入式软件可靠性设计规范汇总 序号 分类 规范要求 人机交互设计 界面分成两类，操作控制类信息、测量监控类信息。每类又分成三级，高优先级、中优先级、低优先级。不同类型的信息内容要分区，不同级别的信息放置位置不同、大小不同、色彩不同。 信息内容直观，不必经过换算 安全关键操作需经过再次确认 色彩只有两个主色调（一前景色，一背景色色），其他只能做点缀色 从任何界面下进入到其他的界面下，最多不得超过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,防止干扰导致的屏幕花屏、regist