运动控制系统软件架构设计的难点：
一.客户的需求总是根据实际的需要不断的增加
由于工业生产的需要，需求总是不断的被提出，而且国内运动控制系统软件起步较晚，还处在不断的摸索当中，更多的时候还是仿照国外运动控制软件进行开发，由于软件开发在整个运动控制系统开发的被动性（相对于机械系统和电气系统，软件系统是最容易被修改的而且其成本也是最廉价的），基于以上因素在软件系统架构设计的时候必须考虑框架的灵活性（容易修改）及可维护性，该点的重要性比保证实时性还要重要，原因是如果我们充分的保证了实时性忽略了灵活性和可维护性，我们的软件或许只能用一年或者更短就不得不做出重写的决定，而现在的市场竞争是很激烈的，我们的开发周期往往决定了老总眼中的经济效益，更坏的是我们辛辛苦苦做出的软件很快就被淘汰了，呵呵这种痛苦的滋味比不发奖金还要难受，毕竟成就感也是我们的精神支柱。
在实际的设计当中根据个人的摸索，框架最好能够做到横向分块纵向分层的办法，这个说起来呵呵真是容易，但是实际做起来并不是那么回事，以后我会就这方面的体会和大家多做交流。
二.机械系统或者电器系统设计的不合理或者达不到要求的精度
国内的机械设计或者机械加工还有一定的差距，而电气系统的编程方式往往又很不灵活往往考虑更多的是逻辑处理，这样很多事情都需要上位软件进行配合，所以不要感觉自己无奈，这也是一种对框架的挑战。
我们做的软件除了功能，工艺之外，最长考虑的往往就是这些问题了。所以运动控制系统的框架设计或许永远都不会有一个完美的绝对的假设前提（因为有太多的实际情况是你无法预料的，包括客户想节省一个开关或者增加一个开关），在实际的设计的时候我采取的方法是，没有什么绝对条件就一个功能它一定是一个独立的实体，尽量让它独立这样以后修改容易不会破坏整体，如果实在独立不了，那么就用中间件设计模式把它和其他耦合的模块隔开，或许到目前为止我中间件模式用的最好了，但是如果没有非常的必要可千万别滥用否则以后搞维护的那个老兄一定会经常在心里问候你及你的家人的，并有可能把你比喻成某种你绝对这辈子不想做的动物当然他说的也有可能是你的上辈子。虽然你听不到，但是你要有一个好的责任心，这样才能有更多的机会。
另外就是机械或者电器系统的改变，也有可能最根本的原因是工艺流程变了，这个改变如果你的框架应付不来其结果往往是灾难性的，很大可能性你不得不忐忑不安的对客户说你要重写你的系统。客户闹心你自己也累。我在实际设计当中体会出一个很有用的窍门，那就是工艺算法尽量用策略模式进行设计，一般情况下一个系统的工艺都是渐变的或者是不同的产品虽然都是同一种设备生产出来的但是加工工艺不同，但是一般情况下描述该系统的数学模型的输入输出是不会变的，这样通过策略模式新老工艺能在一个系统中共存，咱们能够从容的应对。并且我体会出把工艺算法作为系统的中间层是最合适不过的与界面功能分开，同时与通讯层进行打交道。
三.大部分运动控制系统要求都是ms级或者更低
这个不用说了吧，一个控制系统的软件有可能不会超过10万行代码，但是它在1s中内需要采集，处理的次数有可能有几十万次甚至上百万次（当然执行代码量有长有短），这个时候内存的控制，计算量的控制和你的框架设计绝对是相关的，更可怕的是在1ms的级别下，在框架设计阶段内存碎片你必须要考虑，否则你的程序有可能在24小时之内就当机了，这个时候别人怀疑你的水平是有道理的。我采用的方法是最好能够用观测者模式将整个数学模型的管理单独封装，通过接口与其他模块进行交互，这样虽然一定层面上降低了效率，但是克服由于框架设计而造成的内存碎片应当是没有问题的这样程序员也会觉得你的框架开发起来很舒服。一般情况下数学模型最好都是关系型的，如果非关系型的数据在你系统当中很多，很大可能性是你对系统的认识还不足或者说你数学模型还不合理。另外如果你感觉实在是有必要的话设计模式里有一个设计模式是专门处理小对象的，抱歉我还没有用过。
四.软件必须是稳定的
稳定的要求是几个月或者一年不间断工作，不需要进行重新启动，能够对客户的操作进行正常的响应，重启动之后能够迅速恢复启动前的工作状态及恢复各个控制设备的重启动之前的状态参数。
软件的稳定性和框架设计者无关，哈哈我认为这句话是错的。第一段话我已经就原因说的很清楚了。
五.运动控制系统计算量大，算法复杂
呵呵，我想说的是在控制这一块有公式也未必能解决问题，不要指望在书上或者网上就你的问题找到答案或许能找到参考答案，没有过硬的专业知识不要揽运动控制系统框架设计的活还是把机会让给别人吧。
一.客户的需求总是根据实际的需要不断的增加
由于工业生产的需要，需求总是不断的被提出，而且国内运动控制系统软件起步较晚，还处在不断的摸索当中，更多的时候还是仿照国外运动控制软件进行开发，由于软件开发在整个运动控制系统开发的被动性（相对于机械系统和电气系统，软件系统是最容易被修改的而且其成本也是最廉价的），基于以上因素在软件系统架构设计的时候必须考虑框架的灵活性（容易修改）及可维护性，该点的重要性比保证实时性还要重要，原因是如果我们充分的保证了实时性忽略了灵活性和可维护性，我们的软件或许只能用一年或者更短就不得不做出重写的决定，而现在的市场竞争是很激烈的，我们的开发周期往往决定了老总眼中的经济效益，更坏的是我们辛辛苦苦做出的软件很快就被淘汰了，呵呵这种痛苦的滋味比不发奖金还要难受，毕竟成就感也是我们的精神支柱。
在实际的设计当中根据个人的摸索，框架最好能够做到横向分块纵向分层的办法，这个说起来呵呵真是容易，但是实际做起来并不是那么回事，以后我会就这方面的体会和大家多做交流。
二.机械系统或者电器系统设计的不合理或者达不到要求的精度
国内的机械设计或者机械加工还有一定的差距，而电气系统的编程方式往往又很不灵活往往考虑更多的是逻辑处理，这样很多事情都需要上位软件进行配合，所以不要感觉自己无奈，这也是一种对框架的挑战。
我们做的软件除了功能，工艺之外，最长考虑的往往就是这些问题了。所以运动控制系统的框架设计或许永远都不会有一个完美的绝对的假设前提（因为有太多的实际情况是你无法预料的，包括客户想节省一个开关或者增加一个开关），在实际的设计的时候我采取的方法是，没有什么绝对条件就一个功能它一定是一个独立的实体，尽量让它独立这样以后修改容易不会破坏整体，如果实在独立不了，那么就用中间件设计模式把它和其他耦合的模块隔开，或许到目前为止我中间件模式用的最好了，但是如果没有非常的必要可千万别滥用否则以后搞维护的那个老兄一定会经常在心里问候你及你的家人的，并有可能把你比喻成某种你绝对这辈子不想做的动物当然他说的也有可能是你的上辈子。虽然你听不到，但是你要有一个好的责任心，这样才能有更多的机会。
另外就是机械或者电器系统的改变，也有可能最根本的原因是工艺流程变了，这个改变如果你的框架应付不来其结果往往是灾难性的，很大可能性你不得不忐忑不安的对客户说你要重写你的系统。客户闹心你自己也累。我在实际设计当中体会出一个很有用的窍门，那就是工艺算法尽量用策略模式进行设计，一般情况下一个系统的工艺都是渐变的或者是不同的产品虽然都是同一种设备生产出来的但是加工工艺不同，但是一般情况下描述该系统的数学模型的输入输出是不会变的，这样通过策略模式新老工艺能在一个系统中共存，咱们能够从容的应对。并且我体会出把工艺算法作为系统的中间层是最合适不过的与界面功能分开，同时与通讯层进行打交道。
三.大部分运动控制系统要求都是ms级或者更低
这个不用说了吧，一个控制系统的软件有可能不会超过10万行代码，但是它在1s中内需要采集，处理的次数有可能有几十万次甚至上百万次（当然执行代码量有长有短），这个时候内存的控制，计算量的控制和你的框架设计绝对是相关的，更可怕的是在1ms的级别下，在框架设计阶段内存碎片你必须要考虑，否则你的程序有可能在24小时之内就当机了，这个时候别人怀疑你的水平是有道理的。我采用的方法是最好能够用观测者模式将整个数学模型的管理单独封装，通过接口与其他模块进行交互，这样虽然一定层面上降低了效率，但是克服由于框架设计而造成的内存碎片应当是没有问题的这样程序员也会觉得你的框架开发起来很舒服。一般情况下数学模型最好都是关系型的，如果非关系型的数据在你系统当中很多，很大可能性是你对系统的认识还不足或者说你数学模型还不合理。另外如果你感觉实在是有必要的话设计模式里有一个设计模式是专门处理小对象的，抱歉我还没有用过。
四.软件必须是稳定的
稳定的要求是几个月或者一年不间断工作，不需要进行重新启动，能够对客户的操作进行正常的响应，重启动之后能够迅速恢复启动前的工作状态及恢复各个控制设备的重启动之前的状态参数。
软件的稳定性和框架设计者无关，哈哈我认为这句话是错的。第一段话我已经就原因说的很清楚了。
五.运动控制系统计算量大，算法复杂
呵呵，我想说的是在控制这一块有公式也未必能解决问题，不要指望在书上或者网上就你的问题找到答案或许能找到参考答案，没有过硬的专业知识不要揽运动控制系统框架设计的活还是把机会让给别人吧。