基于模型进行嵌入项目的开发，在模型建设方面主要分两个部分：
一个是控制策略、控制算法的建模：这部分所建立的模型在后续的工作中主要用来进行控制仿真、以及自动代码生成及算法实现；
另一个是被控对象模型：这一部分一般不需要生成产品级代码，主要作用是用来验证第一部分模型的正确性，以及能够方便的在模型阶段进行一些控制参数的初始优化。建立被控对象模型的方法很多，常见的方法有：
·数学建模：一般是通过分析控制对象的物理学、化学等规律，建立方程组，推导状态方程，然后将得到的状态方程或者再转化为传递函数，使用simulink中的相应积分微分模块搭建出相应的系统动态结构图。
·物理建模：利用Simulink的Simscape工具箱根据被控对象的物理连接方式（传动、电气、液压、机械）直接使用工具箱中的相应模块进行被控对象的物理结构连接的描述。simscape会根据你定义的连接方式，设定的物理参数，自动进行模型的解算，推导出相应的速率、位移等等，以便观察控制对象的被控效果。
·数据建模：很多时候有一些被控对象没有或者不方便用固定的物理公式进行描述，比如电池、轮胎等等，但是这些被控对象确实存在着一些规律，这时普遍采取的方法是对被控对象进行大量的测试实验，获取实验数据，利用这些数据，可以用Matlab进行数据处理，推导出在一定条件下的多项式公式或拟合曲线，作为被控对象的特征描述。这种方法在电池系统等设计中比较常见。
关于被控对象的描述更多的可能是模型工程师或者是被控对象领域内工程师所应该关心的事情。而策略工程师和电子控制工程师关心较多的还是第一部分模型的搭建和代码实现。这一部分的工作其实也应有几个细分：
·控制策略模型的搭建由策略工程师完成。策略工程师要对被控对象的特性熟悉，并且有相关系统的控制经验，并且能够非常熟练的运用simulink和stateflow工具进行控制逻辑的描述。这一部分可以说是项目的灵魂所在，一个好的控制构架直接决定了最后系统的好坏。要考虑模型的层次结构，比如一般多人参与的项目多用ModelReference，通用的模块可以定义为library；模块之间的执行顺序，算法的效率或者考虑因素是否全面等等。
·将控制策略模型转化为产品级代码是由嵌入式软件工程师考虑的事情，这一部分应该是系统的肌肉，系统可不可靠，是否稳定与健壮，都依赖于这一部分工作了。或者可以称之为软件集成工程师，应熟悉EmbedCoder工具的配置，并与与策略工程师进行合理的数据类型的定义约定，甚至有时候模型的定标工作都由软件集成工程师来进行。通过对模型生成代码和数据接口的合理部署，EmbedCoder生成的代码同样可以达到良好的可读性和可维护性。
·模型的测试工作，一般由模型测试工程师完成，当然这里的职位分工并不是一定的，包括上面的策略工程师和软件集成工程师，在小的项目中可能都是一个人。模型的测试工作中，针对策略工程师的工作结果做的测试叫做MIL，直接利用PC机，在simulink的环境中完成仿真实验；对软件工程师生成代码进行的测试叫做PIL或者SIL（处理器在环和软件在环），这个过程可以检测出代码运行的效率。测试过程主要是针对模型的输入制作测试用例，然后检查输出的结果是否正确。在simulink里输入一般由SignalBuilder或SystemTest等工具进行管理，输出可有ModelVerification工具箱中的模块进行校验。当然，更为实用的方法是使用Excel加脚本的方式，进行测试，使用脚本将Excel中的数据读入workspace中然后再将其对应到模型的输入端口，通过m语言调用运行模型，得到workspace中的输出结果，然后将结果和Excel中的预期结果进行对比，并输出报告。这个过程听起来挺简单，但是确是需要写一大堆m语言的代码来实现的。不过听说mathwork在2013版的时候将会整合测试验证工具，并推出能够实现这样功能的工具，期待啊~~~~
如果再将整个项目的工作继续细分下去，那么还应该有底层软件工程师和硬件工程师，来完成底层驱动、操作系统以及硬件电路板的工作。当然有些技术达人或者有相当技术积累的公司将底层驱动或者叫做硬件抽象层，做出模型元件库，直接在simulink中可以调用，当然不同版本的simulink也有针对当时市场主流芯片推出的自己的TargetSupportPackage，再结合着EmbeddedIDELink工具箱选择合适的编译环境，可以实现模型到下载编译代码到控制器芯片中，一气呵成。
当然实现这样的产品，并保证其高效可靠，中间工作量还是很大的，如果自己来做中间需要用大量的S-fuction对底层硬件进行描述，针对特定的目标板定制tlc文件等等。从项目开发的角度考虑，除非是专门做出这样的定制化的“快速原型”仿真板，否则一般的项目还多是采用较为中间的办法，也就是进行产品化代码生成然后人工进行代码集成，节省了“目标板模型化”的成本和时间，而且利于项目代码文件的管理与维护（说句玩笑话：有时候机器生成的代码自己看一看才够放心嘛，呵呵！），有时候进行问题追溯和代码调整也更为方面和灵活，这一点在底层代码还不是特别完善的情况下显得尤为突出。
其实啰啰嗦嗦写了这么多是想对基于模型的开发有个整体的概括，但是自己入行尚浅，有很多地方还是领悟的不到位，如有看官不幸看到，还请多多指教。
