我个人的理解就是基于CAN BUS的上层应用协议，就好像有菜有锅有调料，不同的人做出来的菜是不一样的，CANopen就是希望建立一个应用标准，和CANopen一样的基于CAN BUS的上层应用还有Device NET、SAE J1939等，对于CANopen的发展历史以及提出这些动动手查查，官方的消息很多哦。但是国内CANopen使用的比较少，原因不详，我觉得这么好的东西不应该埋没呀，或许是因为CANopen栈占用的空间太大？   当然这里还是要感谢CiA主席 蔡豪格，这位可爱的德国老人，坚持开放、免费、非盈利的准则，这种精神值得我们学习。

  对于我个人而言，选择CANopen主要是因为看上了CANopen协议的标准，以及其协议定制的规范性，既有主从模式，又有生产者和消费者模式，紧急上报，时间同步等内容，非常适合我目前的项目场景，并且由于有了一个标准规范，供应商定制协议可以由其发挥，不再浪费相互讨论时间。   实际应用场景来展开说，当前项目主要由中心控制计算机以及多个分系统计算机组成，当前正在使用的方式使用的是一问一答的形式，每一次交互都由中心控制计算机发出，但是实际是中心计算机定周期的获取各个分系统计算机上报的遥测信息，不定期控制分系统计算机、只针对通信分系统进行定期的主动传输，如果使用CANopen协议栈，我们可以同步中心计算机产生同步信号，各分系统计算机根据配置主动上报遥测信息，对于控制有主动数据传输可使用传统的主从模式，CANopen对数据的主动上报可通过配置进行有效上报时间的配置，保证了数据上报的有效性，主从模式下有标准的应答，可以保证了解每一次的操作是否完成。   并且在CANopen中定义了每个从机都会进行上线通知、定时上报自身运行状态，并且从机可以针对本身的紧急错误、事件进行主动上报，保证了主机可以及时的了解下属从机的在线/离线态，以此对各个从机进行对应操作。   以上就是我选择CANopen的原因，不外乎CANopen的设计周全、也建立了一个标准，可以使得产品开发更加的便捷。