复杂系统的软件架构

更高级的ADAS功能正在越来越多地被作为OEM 新车型的亮点，想分一杯羹的Tire1，Tire2也纷纷加入开发者行列。复杂的功能意味着更复杂的架构，能有一个能把整个系统的各个模块和环节调理清楚的总架构师也是很难得。更高级的辅助驾驶功能需要依赖的不同模块，他们的大相径庭的特性和关注点决定了开发方式的多元化，这为一个统一的、简单清晰的、又完善易升级的架构设计提出了挑战。

这两年开始，SOA被各个参与者频繁提及。SOA将逻辑块转变为服务参与方，每一个服务代表一个独立功能，具有统一标准的接口；但非soa的架构在模块划分上本质是一样的，都需要将共同依赖的部分识别出来成为core module, 统一调配计算资源和开发资源。较大的区别在于接口，SOA的接口即服务接口，服务者定义好之后，服务接口是可以被非常灵活地进行消费的，这在本质上不同于接口交互需要在架构设计阶段把所有的发送/接收连接都识别出来，后期有改动需求时需要改动架构的方式，也是一个很大的优势。

(引申问题，cp上的c/s于soa有什么不同？cp上的c/s区别于其s/r的是前者以函数方式传递数据，后者以全局变量方式传递数据，架构设计阶段还是要指定一个server接口和其对应的client接口，但soa只需要设计服务提供方的服务就可以了，后期开发的时候client可以灵活消费)

 

安全性要求更高的模块在实施上是有限制的，比如必须在实时操作系统上运行，这就导致了分布式的硬件架构，以及对应不同的架构方式；架构的“混搭”也给软件架构设计提出了难题，在实现上亦需要增加相应的处理模块。