Vehiclelevel的Functionalarchitecture
Domainlevel的Requirements
什么是架构性需求？
架构性需求是整个系统的最重要的那些需求，它可能出现在产品开发的各个层次和各个阶段，对产品的形态、功能、开发周期等等往往起着决定性的作用。它们最大的特征是：只能在项目早期出现，在项目中期出现往往会导致巨大的工作量，甚至需要将整个项目推倒重来。
典型的架构性需求一般有这么三类（但也有不少不在其中）：
质量需求和非功能性需求，一般是指这个系统的那些功能要完成的有多好。比如刹车系统必须达到ASIL-D标准、最差通信时延必须在1ms以内等等。
决定了解决方案和项目的各种约束条件。比如X项目必须在1年之内完成、某ECU的内存只有100KB等等。
那么接下来以汽车行业的典型“架构性需求”为例，从不同的层次依次展开讲讲。
2.整车级别
整车级别的架构性需求会特别多，就会有下面这些：
车辆的售价：定价20万区间的车，如果中途说改成要卖40万，几乎就是不可能完成的任务。
这个环节离用户会比较接近，大家一看就明白，我就不多讲了。
3.域(子系统)级别域指的是功能域，一般乘用车会分为“座舱域”、“智驾域”、“车辆控制域”、“动力底盘域”等等。这里以座舱域的“3秒内倒车影像启动”展开讲。
种类：非功能性需求
这个需求是由整车级别的R和F同时作用下，才决定了是否需要这个需求：-车辆的售价决定了是否需要高品质
下图是Android的启动顺序，Android的界面要能显示图像，需要至少到下面的NormalMode处。当前行业的优秀水平是15秒以内完全启动。那怎么办呢？
行业一般有几种办法：
驼鸟大法：忽略这个需求，15秒就让用户等吧，反正我这车也便宜。
深度改造法：对Android系统进行深度定制，比如将倒车影像的启动顺序直接提前到跟Zygote并行启动。但这个的研发成本很高，需要引入一套新的GUI系统，因为这时Android的UI系统还没启动完毕呢。
休眠法：某些芯片支持在关机时将当前系统状态保存至Flash上，这样下次开机就能更快了。但支持这个功能代价是很高的，首先是这种芯片就不多，然后还得浪费几个G的宝贵空间用于保存状态。
不下电法：对于纯电车，干脆就不让车机下电，后果就是每天要多掉个几公里续航，并且对系统的稳定性提出了更高的要求。毕竟每次关机都是清除系统垃圾的机会，不关机就没有这个时机了。
4.ECU级别
各个域的功能设计做进一步的拆解，就落到了ECU里面。这里就以MCU的“极少的内存（以KB为单位）”做展开。
种类：约束条件
受限于成本考虑，能由MCU完成的，绝不用MPU(DomainLevel-Functional)
基于RTE运行
很多针对MCU的软件架构都会包含RTE这一角色，其核心的功能就是大部分的线程/Task由RTE创建，并由各个应用共享，这样就可以节省很多Stack的内存开销。
最著名的就是AUTOSAR了，你的程序（应用）被拆成了一个个的Runnables，多个Runnable可以运行在同一个Task中，共享同一个栈。
而一旦你的程序需要基于RTE运行，那么随之而来的，就是要做几件基础的事情：
对你的程序进行配置，主要是配置有哪些Runnable。
配置触发这些Runnable对应的事件Event。
实现这些Runnable。
支持的Event类型
这种开发方式就跟MPU端的灵活开发有非常大的不同。一切都是由事件触发，没有main()函数，并且需要时刻牢记一点：不能block当前的task，否则整个ECU可能都会卡死。
5.模块级别
各个ECU确定了选型后，做了整体的系统设计和软件架构设计后，最终的实现会落到软件模块级别。我们以“禁止动态分配内存”为例展开这部分。
车辆的动力底盘域要绝对可靠(DomainLevel-Requirement)
动力底盘域的某ECU上的软件的可靠性要达到ASIL-D级别(ECULevel-Requirement)
想达到ASIL-D级别，是必然不允许动态分配内存的。(ModuleLevel-Requirement)
动态分配内存有很多好处，但是坏处也不少
内存利用率相对较低
需要内存管理程序，会额外占用内存
产生内存碎片，需要定期清理
不确定性较大
分配内存时，查找可用内存也会引入一定的不确定性
分配内存可能会失败，为避免这种情况往往需要较为复杂的内存回收机制（如Android的OOMkiller），而不定时的触发会进一步导致不确定性）
这又意味着什么呢？这就意味着本来在系统层面上的资源分配会前移到代码编写阶段，对编程模式是个重大的改变。
比如AUTOSAR中的Component配置就包含了这些东西：
需要使用哪些接口，类型是啥？
6.如何识别架构性需求
既然架构性需求是如此的关键，那么如何才能在项目前期将绝大部分的架构性需求识别出来呢？个人觉得主要有两大类方法：
系统的主要功能需求
质量需求和非功能性需求
决定了解决方案和项目的各种约束条件
进行行业对标和调研，对于行业中各个领域的解决方案中特殊的点要知其然且知其所然，而不是简单的想当然，因为这些特殊的点往往就是为了满足特定的“架构性需求”而来的。
结语
三年前，有位大佬问我，架构设计那么多环节，哪个环节最重要？我回答说：“把需求弄清楚最重要”。现在想来，确实如此，万一你漏了一条“架构性需求”，可该怎么办？
浏览量
原文标题：架构性需求是什么
下载发烧友APP
电子发烧友观察
长沙市望城经济技术开发区航空路6号手机智能终端产业园2号厂房3层（0731-88081133）