存算一体-MCU-SOA一起聊
存算一体-MCU-SOA一起聊
参考文献链接
https://mp.weixin.qq.com/s/2T691TEQN7UoRCMueLkTxw
https://mp.weixin.qq.com/s/IUKD4uyvLdvK8UVQCBBLbA
https://mp.weixin.qq.com/s/m_7HsJjJgEX6HVTcZgaxhA
存算分离，该如何分离？
存算分离，作为一种架构潮流，在架构设计和项目规划的时候经常被提及。现如今，数字化转型已经从选择题变成了必修课，企业IT架构的重塑也势在必行，所以我们有必要把这些所谓潮流的东西解构清楚。翻阅了不少资料，也参考了网上一些文章，我们简单来分析一下。
二、计算与存储分离的应用场景计算和存储分离主要应用在哪些方面呢，主要是数据库和消息队列：1、数据库以传统的主从结构的数据库系统为例，主库接收数据变更，从库读取binlog，通过重放binlog以实现数据复制。在这种架构下，当主库负载较大的时候，由于复制的是binlog，需要走完相关事务，所以主从复制就会变得很慢。当主库数据量比较大的时候，我们增加从库的速度也会变慢，同时数据库备份也会变慢，我们的扩容成本也随之增加。因此我们也逐渐开始接受走计算和存储分离的道路，让所有的节点都共享一个存储。也许我们对这样的场景习以为常，其实这就是典型的计算和存储分离设计，现在很多的数据库都在逐渐向“计算和存储分离”靠拢，包括现在的PolarDB、OceanBase ，TiDB等等。所以“计算和存储分离”应该是未来数据库的主要发展方向。2、消息队列消息队列不论是Kafka还是RocketMQ其设计思想都是利用本地机器的磁盘来进行保存消息队列，这样其实是由一定的弊端的。首先容量有限，本地空间毕竟容量有限很容易造成消息堆积，会导致我们要追溯一些历史数据的时候就会导致无法查询，然后在扩容的时候只能扩容新节点，扩展成本也比较高。针对这些问题ApachePulsar出现了。在Pulsar的架构中，数据计算和数据存储是单独的两个结构。数据计算也就是Broker，其作用和Kafka的Broker类似，用于负载均衡，处理consumer和producer等，如果业务上consumer和producer特别的多，我们可以单独扩展这一层。数据存储也就是Bookie，pulsar使用了Apache Bookkeeper存储系统，并没有过多的关心存储细节。这样做的好处就是，只需要关系计算层的细节和逻辑，存储部分采用成熟的方案和系统。其实Kafka也在向这些方面靠拢，比如也在讨论是否支持分层存储，但是是否会实现存储节点的单独设置也不一定，但“计算和存储分离”的方向应该是消息队列未来发展的主要方向。
三、大数据架构中的存算分离应用传统的大数据架构中，数据计算和存储的资源都是共用的，比如CDH的集群配置，每个节点既是YARN计算节点又是HDFS存储节点，其实这种设计也是源于Google的GFS。在Hadoop面世之初，网络带宽很低，为了减少大数据量的网络传输，Hadoop采用了尽量使用节点本地存储的设计，这就形成了计算和存储耦合的架构。近年来CPU算力和网络速度增速远快于存储，数据中心有足够的带宽来传输数据，随着数据量的增长，多副本的设计和考虑也造成了成本的飙升，计算和存储绑定的设计实用性开始变差。随着Spark和Flink等框架逐渐代替MapReduce，批处理和流处理同时共存，也改变了旧有的业务模型，这些都需要新的大数据架构去适配。计算和存储分离的大数据架构开始进入视野。现在很多新的大数据引擎都支持计算存储分离，可以通过外部存储引用的方式进行数据对接，而不是通过ETL加载到本地。Hadoop生态圈也开始拥抱计算与存储分离，Hadoop除了HDFS之外还支持S3，用户可以在私有云或者是公有云上运行Hadoop计算集群，连接共享存储和云存储。这样做的好处也是显而易见的，首先是可以实现计算和存储资源的单独扩容，然后原本分散的数据实现集中存储，打造统一数据湖。更重要的一点，可以真正实现大数据混合云，数据存储保留在本地，机器学习等计算资源部署在公有云，既考虑了安全性，又实现了计算的敏捷。计算存储的分离，也可以方便实现软件版本的灵活管理，存储部分求稳，要保持软件版本的稳定，计算部分求快，可以通过数据沙盒和容器技术，实现不同算力模型的快速交付，各部分独立升级互不影响。这样我们积极可以，构建以企业数据湖为核心的稳态数据资源服务，构建以数据计算为核心的敏态数据能力服务，在实现数据治理的基础上实现数据运营。
其实计算与存储分离这个提法，多少有点噱头的意思，没有那么复杂，当然也没那么简单。还是那句话：没有一成不变的架构，只有不变的以业务为核心的架构意识。
起飞的计算机基础知识
本是程序员必知的硬核基础知识，这是一本非常入门的经典
PDF，看完能让你对计算机有一个基础的了解和入门，是培养你 内核 的基础，我们看下目录大纲
基本上涵盖了计算机所有基础知识，从 CPU 到内存、讲解什么是二进制、磁盘、压缩算法、操作系统、汇编等知识。
来看下内容是怎样的
这个图画的很漂亮啊，看起来就是作者在用心画的，而且排版非常精美。
看起来一点不枯燥
SOA的软件组件部署实例分析
SWC软件部署前言
整个软件的模块的部署需要对需求、软件架构、硬件、中间件平台Autosar，AP/CP都有较为深入的了解。其中流程分为三个主要的阶段：
首先，系统架构设计阶段：专业针对最终实现的功能分配模块，总体讨论ECU融合方案、分配原则，形成初版针对控制器的需求。
其次，系统需求及软件架构设计阶段：通过讨论功能需求涉及的产品能力PC、测试用例Usecase，生成对应的软件模块Module和软件元素SWC。
随后，软件架构设计阶段：进行分配原则、非功能性需求讨论、SWC分配方案编写、专业讨论并更新控制器需求，搭建PreEvision/EA模型。
如上，最终基于软件架构，Module核SWC要分配到各个控制器中，区域控制器VIU中分配到MCU或MPU，MPU中分配到A核、R核，都需要详细的定义。
SWC的软件部署实例分析
本文以高级自动驾驶辅助功能NOA为例，详细讲解实现该功能需要如何定位并细化软件部署过程。
如前所述，所有的部署从本质上就是识别到所能承载软件组件运行能力的核资源，并进行软件集中嵌入该硬核资源的过程。主要包括如下几个关键步骤：
1）识别部署需求
这个阶段设计对部署对象，即需要部署的是哪个功能对应的SWC，该部署过程需要消耗多少部署资源，比如多少核计算能力；相关模块的快速识别，比如如何快速识别出可用于部署的核资源；同时利用设备抽象的概念分理处顶层软件抽象处理模块FDD、底层设备抽象处理模块EDD的颗粒度及部署方案。其中软件模块部署需求中，需要重点界定出AP端、CP端各自的特性，比如CP端非快速启动、快速启动、低功耗等相关特性。
2）搭建物理架构视角的功能链路
|
功能ID |
功能名称 |
子功能 |
非功能性需求 |
|
Xxx |
HWP |
高速跟车、巡航、自动减速、车道保持、自动上下匝道、高速路口减速停车 |
执行器响应能力 传感器识别距离 端对端响应时间 传感器时间同步 功能安全等级 |
|
Xxx |
TJP |
拥堵跟车、巡航、跟停、起步、自动减速、车道保持 |
|
|
Xxx |
ALC/ALCA |
拨杆换道、自动换道、推荐换道 |
|
|
Xxx |
SafeStop |
换道安全停车、本车道安全停车 |
|
|
Xxx |
AES |
自动转向避让、自动换道避让 |
主要是根据功能项梳理物理架构视角功能连路图，同时提取非功能性需求。
整个物理架构视角开发的功能逻辑链路实际是类似于时序图中的对应部分，是考虑将整个功能在工作过程中的数据流进行梳理。
如上图表示了对NOP功能的开启与激活中的自动转向避障控制逻辑PC时序图，各应用模块的产品能力主要涉及对整个NOP系统自动转向控制的能力和交互过程，在我们进行软件组件SWC部署中，首先需要绘制类似上图中的功能交互图，从图中提取我们需要实现的子模块PC，并为每个PC设计对应的SWC即可获得我们需要的总体SWC。
3）梳理SWC软件模块
根据功能需求划分出来的SWC包含如下模块，各SWC分别位于SOA软件架构的不同分层中，对于软件SWC到硬件核的部署过程来说，需要根据其不同的功能子项合理的分配到对应的控制器中。
4）SWC部署到整车控制器
SWC的整个部署过程应尽量遵循如下原则：（01）高等级的SWC尽可能地部署到对应的计算平台中；（02）与传感器、执行器紧密耦合的SWC部署到S&A中；（03）与彼此紧密耦合地SWC部署到一起；（04）休眠后需要工作的SWC考虑功耗问题部署到CP端；（05）功能安全相关的SWC按照ASIL等级拆解后归类部署；（06）信息安全相关的SWC根据具体安全级别需求归类部署；（07）与快速启动相关的SWC部署到CP实时核资源中；（08）与强实时性要求相关的SWC部署到CP实时核资源中；（09）功能链路交互避免过于复杂，接口过多；（10）功能特性相同的SWC尽可能部署到同一个资源上；（11）功能链路时间长度要满足用户体验；（12）高等级的SWC尽可能部署到AP端；（13）资源预留度尽可能多。
从整车功能层分配到控制器的角度可以对如上的SWC软件模块进行总体的功能分配。以自动驾驶系统高性能计算平台为轴心，外围存在其软件模块相关的各个区域控制单元。我们以SOA架构中各个软件子模块为部署的原子模块，为了实现各个模块信息间的通信和控制，我们可以实现如下的软件模块部署。
转向、制动、驱动、悬架等底盘控制单元，由于其功能安全较高，实时性要求较强，且往往与执行器紧密耦合，这类控制SWC可以考虑部署在高性能整车控制单元VDC中。其余如原BCM功能的车身控制及相关的传感执行器、模式控制单元SWC可部署在低功能安全等级PDC中。其余，如电源控制SWC由专门的电源控制单元PMIC进行硬件搭载。
5）SWC部署到HPC内核资源
进一步的，我们以高性能计算平台，针对性的对HPC中的云端单元，从SWC角度分配其功能到内核层面。考虑到不同ADAS功能子模块在SWC中需要遵循的原则，整个部署过程应尽量确保从架构实现、可靠性、高效率、功能安全、信息安全等方面进行全方位考量。
这里我们需要重点说明下关于通用ARM芯片常提到的R核与A核在部署过程中的关系原则。R核是指实时性能高只支持物理地址，并支持内存管理，用于实时性领域。比如，我们在软件部署过程中，通常将与制动、转向等功能安全等级高、实时性也高的软件SWC模块布置在R核中。同时，针对部分实时性操作系统RTOS也布置于R核上进行运行。
A核算力高支持虚拟地址和内存管理，用于应用领域，实时性比R核差些，考虑ADAS功能应用层规控软件功能安全级别有所区别，主要涉及系统管理、应用接口、环境、轨迹预测、规划决策、执行控制/显示等相应的模块。因此，可以将与ADAS应用层相关的软件功能部分布置在A核上。
如下表示了典型的基础软件的部署方案涉及对如下几个重点模块的布局，这里我们以TDA4中主要的核资源核软件Module为主要考虑点。
其中Framework负责为ServiceAPP和Module提供运行环境，并负责实体间通信，让ServiceAPP和Module专注于功能逻辑，以及监视运行环境的状态。因此，我们将服务管理、节点管理、错误管理、模式管理几个“上层服务”应用布置在该应用软件模块中。ServiceManager主要用于大通服务提供端和服务客户端的连接通道，同时提供服务监控；NodeManager主要用于进行进程和节点的生命周期管理、节点间的Com通道以及节点监控；ErrorManagement主要用于进行ADS系统及子系统的错误管理并发送错误报告；ModeManagement主要用于子系统的错误处理、降级管理等。
同时，如上这类框架性服务连同通信管理、执行管理、平台健康管理、状态管理几项都主要布局在TDA4服务级的A核中。
EAL相关的软件模块主要负责封装底层环境，包括底层硬件和OS、整车环境及云端等，提供相应的传感器底层I/O服务、总线通信服务，实现软硬件分离。因此，通常讲设备抽象模块EDD模块部署在EAL之上。
Core表示一种核心模块，主要是提供顶层应用框架与底层EAL的通用服务，并为ADS系统提供通用功能，同时为这些通用服务定义真正的外部环境和部署结构。Module表示支持自动驾驶开发的基础模块，包含通常的感知、融合、规划、决策等几个模块。
这类软件模块处理任务包含：
- 资源管理：系统、总线、传感器、存储、资源配置等管理；
- HPC信息处理：DNN处理、CV处理、并行处理、算法嵌入等；
- 协调端系统：传感器信息、车身信息、驾驶信息等；
- ADS功能服务：数据记录、诊断等
从如上功能单元不难看出绝大部分Core资源所涉及的软件模块具备较高的功能安全等级和强实时性要求。同时从运算角度将，可以将其中的软件部署拆分成两个部分，其一是针对图像处理、深度学习模块的感知单元，这部分往往在功能安全上要求从ASILB起步，而后端规划控制和决策执行，则是更加倾向于更高级别功能安全等级。多数规控模块要求达到ASILD级别功能安全，且由于涉及与执行器之间的交互，很多情况下本身系统上层的交互信号安全等级也较高，可达到ASILD级别，同时考虑自动驾驶本身安全性需求，需要执行控制过程往往具备强实时性。因此，感知、融合这类前端计算量大，安全等级一般的SWC可部署于A核中间，而后端规控、执行安全等级、实时性都较高，可以考虑布置在R核中。为了减少对于后端MCU的计算压力，可以将轨迹规划和决策放在前端SOC的R核中，而执行控制、反馈调节等MPC过程可以考虑放在外围MCU中。
如下图表示了功能软件主要部署的几个大模块，以TDA4作为SOC表示的对系统功能需求相应的A核和R核部署方法。
参考文献链接
https://mp.weixin.qq.com/s/2T691TEQN7UoRCMueLkTxw
https://mp.weixin.qq.com/s/IUKD4uyvLdvK8UVQCBBLbA
https://mp.weixin.qq.com/s/m_7HsJjJgEX6HVTcZgaxhA
