最近看到几篇关于Simulink及AutoSar的Blog和Paper，感觉比较有意思，转载备忘之。

1. 看衰Simulink及AutoSar

From：Tumiz的技术天地

https://blog.csdn.net/tumiz/article/details/48660191

作者：Tumiz

其实Simulink和AutoSar的开发流程现在是越来越流行，这篇文章里的一些观点还是有失偏颇；

毕竟技术的惯性还是很厉害的，一些不适用Simulink/AutoSar的软件可以通过在系统设计的过程中合理划分各模块来最大程度地适配相应标准。

原文内容

simulink做为领域特定语言DSL，仅适合和数学相关的算法开发，不适合扩大应用范围，而现在的情况是simulink被滥用，而工具开发商还在推波助澜。

汽车领域内simulink的适用的开发范围是有限的，那就是算法开发。

除此之外，用simulink开发并不合适，如ADC、CAN收发、故障管理、网络管理等，对于这些与底层相关的IO处理程序无论是开发效率或是运行效率simulink都不及C/C++。

领域特定语言在特定的领域才有其优势，在此领域之外反而是弄巧成拙。

很多汽车工程师都用simulink建模并生成代码，认为其学习门槛低、可读性强、基于模型建模和自动代码生成是未来趋势应该完全simulink开发；

其实是一种误解，simulink作为一种图形化语言的确学习门槛低可读性强，这是因为simulink屏蔽了底层信息仅体现数理逻辑的缘故。

也正因此simulink缺乏了表现底层的能力，可以说专业性不够。

描述相同的底层功能，simulink的工作量要比C/C++多得多，运行效率却要差不少。

很多汽车工程师醉心于研究各种Matlab/Simulink的使用技巧，本来用C/C++很容易解决的问题，为了使用Matlab/Simulink而耗费了更多时间。

m语言和simulink作为数值计算领域内的特定语言，用其做算法开发十分容易，但是它并不能在所有领域通用，开发底层它不如C/C++，开发界面不如Java，开发网页不如HTML/Javascript。

当前，汽车控制器的软件除了硬件驱动、简单的调度之外就是控制算法了，功能性方面的开发并不是很多。

换句话说，现在的汽车控制器偏向于计算，而且计算量还不大，相对于手机或PC来说可以是很小，几乎没有存储功能，人机交互、机机交互的工作量（广义的IO处理）也很小，所以用simulink开发大部分上层程序是没有问题的，但是随着汽车控制器承担的功能越来越多，交互的工作会越来越多，随着智能化的发展，存储的需求会越来越多，而这些都不是Matlab/Simulink所擅长的，因为这些不是数学问题。

再谈autosar。

autosar作为宝马等整车厂提出的控制器软件架构标准，目的是为了切割划分控制器软件的层次，便于把软硬件包给不同的供应商来做，意图改变当前供应商软硬一体的格局，降低对某一供应商的依赖。

但是据我的实际使用体验，autosar的层次划分不清晰，架构设计实在糟糕。

首先，层次划分，ADC、CAN收发、故障管理、网络管理、传感器驱动等都是放在应用层来做，这些通常是放在底层完成的工作，却因为便于底层软件的固化（开发应用软件过程中不用改动）而被放在了应用层，这类似于windows的驱动安装，本来是底层的驱动被当成应用软件安装。但是windows驱动安装后仍然位于底层，而autosar里面这些程序生来就在应用层。

然后，这种架构设计糟糕在哪里呢，to be continued....

个人观点

Simulink/AutoSar偏向于算法仿真，我们在开发过程中可以用来快速验证算法，生成的代码也是可以优化的嘛。

算法验证完毕，封装算法，底层操作则可以通过C/C++来实现。