目前新一代的电子电气架构，大致可以分为如下四层：
三、面向信号与面向服务混合架构设计
电子电气架构主要提供了整车功能的开发框架，无论面向信号还是面向服务起点都是CustomerFeature，最近几年在电子电气架构领域基于模型的开发方法（MBSE）被大家广泛采用，基于模型用例驱动能够更好跟踪用户需求与最终的技术实现（软件、硬件设计）。采用基于模型的开发虽然各家的开发方法论及工具链细节上存在差异，但是总体的流程基本一致。
图5：基于模型的EEA开发流程3.1用户特征及需求（CustomerFeatureandRequirements）
a)功能需求（FunctionRequirements）
功能激活条件
激活/关闭/进行中的系统行为
功能激活/关闭的条件
b)非功能需求（Non-FunctionRequirements）
c)平台/跨域需求（Platform/DomainRequirements）
车辆配置需求
人机交互需求
图6：用例图
3.2逻辑功能架构(LogicalArchitecture)
基于上一步的用例及功能需求，我们针对每个Feature（UseCase）进行逻辑功能架构设计，在这一步我们会划分逻辑功能组件LC（LogicalComponent），LC是一个抽象的组件它独立于具体的硬件和软件实现，同时LC在整个架构平台是一个重要的数据库，应该形成一个LCLibrary，并且LC的创建、更新由架构工程师（SystemArchitect）来统一负责，功能工程师（FunctionDesigner）在进行逻辑架构设计时向架构工程师（SA）提出LC的需求，同时架构工程师（SA）负责LC向系统的分配。
我们来看一个具体的例子，如下图有两个整车FeatureX和FeatureY，FeatureX在逻辑功能架构设计时由Sensorfunction1、Function1和ActuatorFunction1三个LC实现，FeatureY在逻辑功能架构设计时由SensorFunction1、Function1、Function2、SensorFunction2、Function3、Function4、Function5、Function6等9个LC组成；
图7：逻辑功能架构图为了保证逻辑功能架构与后面AutoSAR软件架构的继承性，逻辑组件LC的接口设计应遵循AutoSAR的标准，在逻辑功能架构设计阶段，不同的方法论和工具链会有些许的差异，例如PREEvision中我们通常会针对每个Feature创建ActivityChain，另外像BEG等用IBM工具链的厂家会在Rhapsody中创建整车层级、系统层级到逻辑组件层级的泳道图，从而进行功能的细化分解形成LC，最后进行LC的部署，上述逻辑架构图中的每个逻辑组件都将被分配到对应的Sensor、Actuator、ECU或计算单元中，将图7中的逻辑组件分配到图3中的架构层级各节点中，形成的矩阵如下：
3.3服务架构(ServiceArchitecture)
3.4软件架构(SoftwareArchitecture)
图10：软件架构视图从上图我们可以看到对应部署在SensorActuatorECU1的Fucntion1，部署在IntegrationECU2的Fucntion2、以及部署在SensorActuatorECU3的Function3等非服务化的逻辑组件LC，其在软件层面会设计对应的ClassicAutoSARApplicationSWComponent,以及S/RInterface及C/SInterface。