今天本来是想简单的介绍一下dSPACE的Automotive simulation models（简称ASM），但是想想还是把dSPACE这个公司的整个开发流程写一下。这样也可以了解一下汽车的整个软件开发流程是什么样子，开发过程中一般会用到什么东西以及开发标准是什么。

介绍顺序如下

1 dSPACE公司简介

2 dSPACE的工具链

3 dSPACE的优缺点

4 总结

---

1 dSPACE公司简介

不知道大家是否知道dSPACE公司。他们自称为embedded success，听起来可厉害了。

下面是公司主页

主页 – dSPACE​www.dspace.com

 

在主页浏览一圈，然后再进入汽车相关产品介绍，就可以看到下面的画面。

汽车相关产品介绍界面

通过这个页面的介绍，相信大家也可以看出他们公司是做什么的。关键词有仿真，硬件在环，数据记录，AUTOSAR， 虚拟驾驶。最核心就是仿真。他们是参与整个V-cycle开发的。也就是说，他们除了不给你提供无人驾驶相关的控制算法以外，其他所有开发所需要的硬件，开发软件（工具）都给你提供。所以，只要购买相关产品，我们就可以方便的利用他们的软件包。这个跟matlab的toolbox 很类似。比如上面图片的最左下角有个ADASIS V2 Horizon， 这个东西是一个正在开发的高精地图标准协议（或者说是正在变成标准）。那么这个词汇为什么会出现在他们的产品介绍里面？ 因为ADASIS V2 Horizon既然是个协议，他就需要按标准编码解码，然后提取数据。这些都需要人力去做。但是，dSPACE就提供（卖）这个协议的SIMULINK blockset。需要用到这个协议的公司就可以直接通过购买减少开发成本。这类商品就是dSPACE的收入来源。同理，开发无人车驾驶中所需要的CAN通讯，无线通讯，LAN通讯等等标准协议，都会被他们拿来打包成一个blockset， 然后再出售。

 

2 dSPACE的工具链

他们为什么卖这种服务？这种服务为什么会有市场？为什么他们的开发工具敢卖那么贵？这就需要对他们的产品有整个理解。

简单来说，他们的研究人员把很多汽车软件研发相关的软件打包，出售。卖出的产品是library，他们称之为库，也称之为Block set。 Block set 意味着模块，也就是说他们是MBD（Model based design）的开发方式。也就是所有的算法都以SIMULINK的方式构建的。

下图就是dSPACE公司的高自由度汽车仿真模型ASM的SIMULINK截图。

（每个模块里面还有很多很多subsystems）

 

为什么非要在SIMULINK上构建算法？在已有的代码里面添加内容不就完了么，干嘛费劲的在SIMULINK里面做？据我所知，这是因为ISO26262 功能安全标准里面，规定了要用MBD。下图是汽车开发的V-cycle（就是一种解释开发顺序的图）。

 

 

下面来看看他们的提供的主要服务。

https://www.dspace.com/en/inc/home/products/products.cfm#filterterms=term-344

 

 

上图中都是分散开解释的，所以会觉得有很多内容。但是这些东西都可以通过他们的核心软件model desk， motion desk， control desk（还有很多，只不过我只用过这些）。

整个工具核心就是ASM。也就是车辆仿真模型。在车辆仿真模型构建好的情况下，通过他们自己的model desk可以修改ASM模型里面的参数。也就是说不用到每个SIMULINK的subsystem 挨个找相关参数，就可以直接在model desk 配置车辆参数。相信我, ASM可调节的参数详细到整车厂估计都拿不出所有数据。（PC端）

下图就是model desk的主页面。里面可以看到可以调节environment，vehicle dynamics，trailer,soft ecu, engine,drivetrain,eletric components…等等。其中很多东西就是需要额外购买相关block set才能用。图片中这个是满状态的ASM。（PC端）

 

 

Motion desk 是可以通过model desk 生成的模型将其可视化的工具。也就是把车辆，周边环境，周边车辆，交通情况，行人等都可视化的工具。可以生成很复杂的交通环境。这里没什么特别要交代的。（PC端）

以上所有的东西都是基于PC完成的。而汽车是嵌入式的系统，所以要生成c代码。在modeldesk，我们可以选择按照特定标准的协议生成代码，然后需要把这些代码build到real time embedded 系统中。一直到build 都是由pc端的model desk完成。但是一旦build，并将整个系统放入嵌入式设备之后，就没有model desk能做的事情了。

但是嵌入式设备中跑的系统我们想观察，有些参数我想更改，也要log 数据。那么这步骤就是由control desk完成的。这嵌入式设备当然dSPACE也会提供。比如Autobox,DS1006 （嵌入式设备）。设备价格也是相当的贵。

那么有些人就好奇，算法build好了，在嵌入式设备中开始运行了，so WHAT？ 之后就是最重要的部分了。这部分就是硬件在环仿真。

想象一下，如果一个整车厂要开发新的车，新的控制算法。但是整车厂不可能说新车的所有部件都做出来后才开始开发软件代码。那么就需要有一个虚拟的车可以让工程师按照新开发的车辆调节数据。只要数据调节好了，我们就可以把这个虚拟的车当作真车来进行软件测试。理论上，如果ASM足够好的话，参数足够的话，ASM应该可以提供跟真车一样的行为。那么把这个虚拟的车加载到嵌入式系统中的话，嵌入式系统中跑的其实就是真车一样的虚拟车（包括周边环境，传感器，车道等等内容）。这时候，我们只要在嵌入式系统提取I/O并连接到整车厂开发的ECU，那么对于开发的ECU来说，它就是接收到了跟真车行驶时候一样的input。工程师就可以通过ECU的反馈来判断开发的软件是否有问题。

这就是dSPACE整个工具链。

所有的一切都是为了最后做硬件在环仿真。

但是！我们研究无人车的话，可以参考dSPACE的ASM学习车辆动力学相关知识。那真的详细到不能再详细了。我们可以理解车辆的每一步的控制逻辑。理解好了，再去配合场景构建+传感器的行驶环境，构建虚拟驾驶环境，算法就直接可以在SIMULINK构建。且因为是基于SIMULINK开发，测试好的代码可以直接拿到别的支持MBD的地方使用。

dSPACE的工具链对于无人车研究起到的作用跟prescan很类似，传感器+虚拟环境+汽车动力学仿真。但是prescan不提供硬件，block set（CAN block set，satellite block set, ADASIS v2 Horizon, Wireless communiation）这种东西。所以做试车实验什么的话，dSPACE会更加方便一些。也会更贵一些。

有时候感觉，光看他们的产品就可以知道汽车软件开发要干些什么。。。

 

3 dSPACE的优缺点

优点：

复杂度很高，可以调节各种参数

软件硬件延伸性很好

MBD可以让每个逻辑的来龙去脉都变得很清晰

提供汽车相关产业的几乎所有眼神服务

 

缺点：

贵，贵，贵，啥都得买

太复杂

学起来费劲

服务产品概念很抽象（理解他们为啥敢卖卖的这么贵，就花了我很长时间）

 

4 总结

今天简单讲了下dSPACE的工具链。详细的内容其实都在他们的官网里。

对于无人车系统开发，其实和prescan的区别并不大。但是如果涉及到实车测试什么的，dSPACE的工具链就要强大很多了。因为他们提供的是产业从头到尾的解决方案，而prescan和carsim只是个软件。这也是为什么他们敢卖那么贵的原因，因为从头到尾的服务基本没什么公司在做。

 转自：https://zhuanlan.zhihu.com/p/38266888