前一篇文章介绍了软件架构设计的相关方法,本篇用一个实际案例进行实验练习。
假设我们已经完成软件需求分析的工作,得到了若干条软件需求,现在需要根据这些软件需求来设计应用层架构。我们以电机控制器(MCU)软件需求为例:
- 当MCU被唤醒时,MCU软件应进入Init状态,发送CAN信号mcu_state为0。
- 当MCU软件初始化完成后,MCU软件应从Init进入Standby状态,发送CAN信号mcu_state为1。
- 当MCU软件采集到母线电压大于200V,且接收到CAN信号vcu_mcu_state_req为1时,MCU软件应从Standby进入Work状态,发送CAN信号mcu_state为2。
- 当任何故障触发时,MCU软件应从任意状态进入Fault状态,发送CAN信号mcu_state为3。
- 当MCU状态为Work时,MCU软件应采集三相电流、母线电压及电机转子位置信号,并控制电机输出扭矩等于接受到的CAN信号vcu_trq_req。
- 当MCU状态为Work且接收到CAN信号vcu_mcu_state_req为0,MCU软件应从Work状态进入Standby状态,并停止PWM输出。
- 当MCU软件采集到任意一相电流大于800A,则触发过流故障,MCU软件应停止输出PWM。
- MCU软件应实时发送CAN信号:电机转速mcu_spd,母线电压mcu_v_dc,输出扭矩mcu_trq。
一、软件组件划分
通过分析每一条软件需求,可以发现整个MCU应用层需要有这几大块的功能:
- CAN信号接收:接受VCU(整车控制单元)的控制指令。
- CAN信号发送:下发MCU的系统状态。
- 模拟信号采样:采集电机控制所需用于控制反馈、诊断及状态判断的模拟量信号。
- 故障诊断:诊断电机故障,根据不同故障响应触发不同的故障保护。
- 状态管理:根据请求指令,切换不同的工作状态。
- 电机控制:控制电机输出扭矩跟随请求扭矩,并使效率最优。
根据这些功能块,设计对应组件即可,输出物就是下方的组件列表了:
二、组件接口定义
根据软件需求,和组件划分,容易分析出组件之间需要哪些接口来传递信号:
需求1,用到的组件有MSM和CPS,因此MCU状态这个信号需要由MSM传递到CPS,同时MCU状态的CAN信号需要由CPS传递到BSW。得出两个接口:MSM_McuState和CPS_McuStateCAN。(接口命名分成两部分,下划线前为其输出组件)
需求2,在以上两个接口的基础上,需要判断BSW初始化状态,因此,新增一个接口BSW_InitState。
需求3,在上述3个接口的基础上,需要采集母线电压,传递给MSM,而MES需要从BSW获取母线电压AD值,因此再新增两个接口:BSW_VoltDcAD、MES_VoltDcPhy。另外,还需要接收VCU的请求指令,因此再新增两个接口:BSW_VcuStateReqCAN、CPR_VcuStateReq。
... ...
在分析完每一条需求之后,按照接口数据的精度要求和符号,选择合适的数据类型,并整理得到组件接口定义过程的输出物:接口列表。
三、标定、观测量
这里我们简单添加几个标定、观测量到架构设计中,大家在实际开发中,根据需要与经验设计即可。
四、数据流分析
从上述软件需求描述可以总结出,MCU的主要功能是转矩控制。我们以此为例进行数据流分析,得出结论为此数据流向能够满足扭矩控制的功能:
五、任务调度设计
首先分析各个组件的执行周期:
FOC作为控制环路组件,其实时性要求最高,因此其调度周期与PWM周期一致或为PWM周期的一半,由中断触发。
MES作为FOC的反馈采集,其实时性要求与FOC一致。
FDM、MSM作为状态控制与诊断保护,其实时性要求略低于控制环路,因此将它们的调度周期设置为1ms。
CPR、CPS作为CAN通信的输入输出,实时性要求最低,将其调度周期设置为10ms即可。
根据不同调度周期,设计两个任务,根据数据流方向对任务内部的组件进行排序,就得到了这一步的输出物之一:任务列表。
为避免多个任务同时执行造成的负载率尖峰,我们再将不同任务的调度时间错开,这里以0.5ms为单位,设计任务调度表:
最后再根据每一条软件需求对我们设计的架构进行审视,发现所有需求均能覆盖。至此,软件架构设计的工作就全部完成了,将应用层架构设计输出物与底层开发人员对接即可。以上就是本章的实验内容了,大家在实际工作中的软件需求数量可能几十倍、甚至几百倍于上述的需求数量,设计出的架构也因此更加复杂,但其原理和方法都是一样的,只需掌握方法积累经验,架构设计这一活动就能轻松完成了。
提示:软件架构设计作为软件开发周期的前期工作,其完成质量会对后续工作造成很大的影响,一份优秀的架构设计可以让后续工作变得简单。