车载SOA软件架构设计

根据基于模型的系统工程方法和以下面向服务架构的建模语言(SOAML),提供了用于面向服务和软件架构建模的各种元模型的详细信息。SOA和软件层元模型大致分为两类:核心建模(数据)和图表(可视化)。
SOA设计-核心模型设计
这些是为每个特性或系统建模SOA和软件体系结构的核心。
服务:服务可以通过定义的接口提供可用的功能。每个服务都有一个用于服务注册和发现的唯一ID。服务使用者应使用此ID识别服务,并根据定义的接口使用功能,尽管服务定义不一定要有使用者。服务的类型包括:
  • 硬件抽象服务:基于ECUs功能和硬件外围设备(例如传感器、执行器),定义硬件抽象服务。这些服务应该在软件平台级别提供。

  • 平台核心服务:所有夸应用程序集群和域的公共服务都需要在软件平台级别定义和提供。

  • 域核心服务:在一个应用集群中,跨不同应用层序的公共服务定义为域核心服务。

  • 应用程序服务:特定于系统的每个应用程序或功能的服务,需要定义为应用程序服务。

服务提供者:服务提供者是具有提供服务功能的特定角色的服务的实例。服务提供商根据定义的服务接口提供服务。
服务使用者:服务使用者是具有使用服务功能的特定角色的服务实例。服务使用者需要确保从提供者获得定义的服务接口。
服务端口:服务端口是服务提供者或使用者之间互相通信的接口点。
服务接口:服务接口是服务提供者和使用者之间数据交换的定义。它定义了向使用者公开的服务的属性。服务接口具有以下内容:
  • 使用getter和setter将字段转换为属性;

  • 方法(请求和响应);

  • fire-and-forget 方法(请求无需响应);

  • 事件和事件组;

方法-请求和响应:这是服务接口的一部分,在客户端或者服务器中调用方法并期待得到确认。
fire-and-forget方法:这是服务接口的一部分,在服务接口中,客户机在不等待服务器确认的情况下调用该方法。
事件:这是服务接口的一部分,服务角色在其中更新数据或传递操作。服务使用者可以订阅事件或者事件组。
属性或字段:这是表示服务器中某些数据的服务接口的一部分。服务器应该通过公开getter和setter方法向使用者提供该数据的访问。
参数:它定义一个方法的输入或返回参数(请求/响应和fire-and-forget方法)。
面向服务的体系结构:每个特性或系统的SOA包括具有id的服务定义、服务角色(提供者和使用者)、服务器接口定义以及与定义的服务接口相关的相互接口的服务角色。
组合:用于按层次结构组织软件组件。
应用软件组件(SWC):它表示在软件体系结构层具有足够粒度的给定功能。它应该足够细化,可以部署在单个硬件组件上。SWC应为AUTOSAR经典或自适应或非AUTOSAR软件组件。如果是AUTOSAR经典或自适应,则必须按照标准AUTOSAR定义遵循类型-原型-实例结构。
软件端口:软件端口存在于软件组件上,表示操作(如果是客户端服务通信)或数据元素(如果是发送方=接收方通信 ),提供或订阅的数据,发送方-接收方接口或客户端接口被分配给软件端口。
软件组装连接器:通过使用软件组装连接器(软件级数据流)连接软件端口,使软件相互连接。
客户机服务接口、操作和参数:如果软件端口以客户机和服务器模式交换数据,则分配给它们的接口称为客户机服务接口。这个接口需要包括每个操作的操作和参数(输入和返回)。
发送方=接收方接口和数据元素:如果软件端口以双向模式交换数据,则分配的接口称为发送方-接收方接口。此接口需要包括数据元素(表示交换的数据)和数据类型分配。数据类型应为应用数据类型和实现数据类型。应根据这些数据类型定义计算方法。
SOA设计—图表设计
SOA设计和软件架构( architecture)数据应以表格格式或图表形式可视化。
应使用定制的表格格式来可视化SOA设计数据和软件架构定义面向服务的体系结构图(SOAD):该图应可视化给定功能或服务、服务角色(服务提供者和服务使用者)、服务端口和服务接口。下面是SOA图的示例视图:
软件架构图(SWAD):一旦SOA定义完成,就应该定义软件组件方面的服务部署。此图显示了用于数据交换的软件组件、软件端口及其之间的连接(软件程序集连接器)。还应显示每个软件组件上部署的逻辑功能。下面是软件架构图示:
车载SOA软件架构:服务设计
  • 服务定义
服务使用SOME/IP总线向客户端提供一些功能。所提供的功能既可以作为请求消息公开,也可以作为发送消息公开。
  • 服务集群划分
服务是基于子系统重新划分群集的。
  • 服务描述模板
服务描述必须包括以下信息:
服务描述:服务目的的简单描述。
消息类型:方法或事件。
讯息名称:讯息名称。
消息描述:消息用途的简短描述。
消息输入参数:此规范类型使用的输入参数的完整列表。
返回参数:此规范类型使用的返回参数的完整列表。
此外,必须描述枚举和自定义类型。
 AUTOSAR-AP平台SOA相关技术规范概述
AUTOSAR-AP平台采用SOA方法论,主要涉及一种自适应软件产品的开发,是一套包括软件分析、设计、开发、部署在内的复杂工作流程。主要包括两个方面:工作流定义与成果物定义(如图2-2)。具体描述如下:
流程定义
AP平台的方法论作为CP平台的扩展,其引入了新的概念,AP平台软件的实例是在进程的上下文中执行。AP平台引入了“机器”(Machine)的概念,“机器”是虚拟化的ECU,一个可以部署软件的实体。它可以是真实存在的处理器,也可以是一个虚拟机,AP软件则运行在某一特定的“机器”上。
(1)开发服务接口(Service Interface)
AP平台是一个面向服务的软件架构(SOA),基于AP平台的软件开发,首先需要进行服务接口的设计。服务接口可以由事件(Events)、方法(Methods)和字段(Fields)组成,是生成软件组件头文件的基础。
(2)开发通信结构(Communication Structure)
OEM在设计阶段需要指定预期“机器”(Machine)的通信结构以及相应的配置参数,包括机器的所有网络端点和服务发现地址端口等。这一步将产生一个可交付的“机器设计”(Machine Design),一个特定的“机器”模型将引用一个特定的“机器设计“ 模型。
(3)开发自适应应用软件(Adaptive Application Software)
自适应应用软件开发从软件组件(SW component)的设计开始,软件组件是通过其端口(Port)定义的,每个端口实现一个服务接口。基于服务接口描述,生成包含实现软件组件的头文件。开发人员在此基础上实现软件组件的核心功能。
(4)开发自适应平台软件(Adaptive Platform Software)
与应用级软件类似,平台级软件可以由基于标准化服务接口的软件组件组成,也可以直接实现而不需要软件组件模型。
(5)定义和配置机器
包括了功能组状态和每个状态超时的定义,进程到特定机器的映射,以及平台服务(例如NM、DoIP) 和基础模块(例如日志)配置等。此过程会产生一个独立于服务实例或应用程序的机器清单(Machine Manifest)。
(6)集成软件
软件的实现和编译完成后,需要集成到一个可执行文件CExecutable)中。通过进程来定义特定机器上可执行文件的实例化,每一个进程会产生一个执行清单CExecution Manifest),其中包括了进程及其启动配置。
(7)定义和配置服务实例(Service Instance)
首先对服务接口进行部署,然后定义服务接口的实例,并决定是否提供或使用该服务实例。其次要建立服务实例到机器的映射,以及服务实例到端口的映射。此过程会产生进程所需的所有服务实例清单(Service Instance Manifest)。
(8)生成软件包(Software Package)
将可执行文件及所需清单整合为软件包上传到机器上,而无需重新刷写。OEM可以将软件包存储在后端服务器中进行统一管理。
成果物定义
由于AUTOSAR的工作流包含了整个汽车软件开发流程,涉及多个开发角色,因此需要各个开发角色之间有信息交互,为了保证信息不出现二义性,需要对各个环节的工作成果物规则进行定义。同时为了信息的保存、传输、交互的需求,需要定义这些成果物的载体,ARXML就是定义了不同流程成果物的载体,使用不同的标签来表示不同的信息及流程,这些标签的定义就是AUTOSAR的数据元模型(如下图)。
MO使用Ml级规则生成的可运行软件实体,例如车门控制的可自行软件组件
Ml: 使用M2级规则定义软件组件,例如车门控制的软件组件,软件组件的表现形式可以是ARXML,C/C++语言或各类文档。一般情况下会使用工具链以ARXML的形式定义软件组件的框架,然后导入下游工具链生成目标语言。或直接生成目标语言框架,然后手写代码的形式完成整体的软件组件;
M2: 使用M3级规则定义使用AUTOSAR开发的元素、语法及规则,例如软件组件,port口,机器,清单等。该级别的元素与具体的功能无关,类似于各类开发语言的语法;
M3用于定义M2的元模型。

本文摘录自AUTOSEMO撰写的首个车载SOA软件架构技术规范,侵删。

(0)

相关推荐

  • 【上汽零束SOA】云管端一体化SOA软件平台系列介绍之四:车云一体架构篇

    上汽零束基于SOA的软件架构理念,将车云能力服务化,构建云管端一体化SOA软件平台,打造千人千面用户体验,让车成为有生命力的人类伙伴.要实现云管端一体化SOA软件平台,车云一体架构就是不得不讨论的话题 ...

  • 基于SIMULINK开发面向服务的汽车应用架构(SOA)。

    汽车功能越来越多地由软件定义,使它们更容易被黑客攻击.汽车电气工程向面向服务的架构演变,无论是向ADAS或信息娱乐系统添加新功能,还是修补漏洞,OTA更新都是一个有价值的解决方案.面向服务的架构(SO ...

  • 《车载SOA软件架构技术规范1.0》解读1:SOA架构技术概述及技术规范现状

    背景: <车载SOA软件架构技术规范1.0>是由AUTOSEMO撰写的首个车载SOA软件架构技术规范,这是首个面向汽车行业SOA软件架构的理论体系.近期,AUTOSEMO将组织针对本规范的 ...

  • 基于SOA架构的开发策略详解

    面向服务的开发模式已经是为大家熟知的下一代智能汽车开发模式了,由于SOA(Service Oriented Architecture)架构的灵活性和可扩展性,而这个恰恰与「软件定义汽车」的思路不谋而合 ...

  • 基于Autosar的SOA软件开发设计详解

    知圈 | 进"域控制器群"请加微13636581676,备注域 面向服务的架构SOA的出现可以打破车内静态交互模型,并且建立功能灵活治理的系统架构.确保新增功能的实现可以与车辆原有 ...

  • 208份AutoSar官方文档

    什么是AUTOSAR? 介绍一下: - AUTOSAR是由150多家汽车制造商和汽车供应商企业组成的联盟. - 它是AUTomotive Open System Architecture的简称. - ...

  • 「软件定义汽车」时代下的SOA架构设计 !

    导读: 本文由几何四驱授权发布,作者为赵玉龙. 为了真正实现软件定义汽车.软件驱动创新,从技术角度来看,汽车软件架构需由"面向信号"迈向"面向服务(SOA)". ...

  • Autosar VFB简介

    虚拟功能总线是对AUTOSAR提供的所有通信机制的一种抽象,是所有软件组件进行交互的桥梁.通过虚拟功能总线,软件组件之间的通讯细节被抽象出来,软件组件通过AUTOSAR定义的接口对通讯进行描述,即可最 ...

  • AutoSar在自动驾驶开发中应用原理

    Aimee 汽车应用软件开发已成为汽车开发过程中最复杂,最关键的活动.AUTOSAR(汽车开放系统架构)为汽车电子控制单元(ECU)开发了标准化的开放软件体系结构,是主机厂.供应商以及工具和半导体供应 ...

  • 《车载SOA软件架构技术规范1.0》解读3:车载SOA软件服务设计规范

    《车载SOA软件架构技术规范1.0》解读3:车载SOA软件服务设计规范

  • 资料下载——《车载SOA软件架构技术规范1.0》

    2021年6月17日-19日,中国汽车工业协会主办的第11届中国汽车论坛在上海嘉定举办. 其中,19日上午举办的主题论坛"共创软件定义汽车新生态"上,上汽零束软件分公司首席架构师孟 ...

  • 新规范,新标准|上汽零束发布车载SOA软件架构规范1.1

    2021年9月27日,世界智能网联汽车大会在北京举行,上汽零束首席架构师孟超在会上发布了AUTOSEMO<车载SOA软件架构技术规范1.1>(以下简称规范1.1),作为中国工业和信息化部智 ...

  • 驾驶必备,车载磁吸设计,一放即充,亿色车载磁吸无线充电器体验

    这两年无线充电越来越好用了,平时不管在家还是出门,只要有能无线充电的设备,就可以省去数据线的麻烦,更加便捷的充电,特别是去年iPhone 12加上了MagSafe技术之后,无线充电就更省事了.现在市面 ...

  • 嵌入式软件架构设计分层思路

    在正规的项目开发中,项目往往是并行开发的,也就是说硬件设计.底层软件设计.应用软件设计等是同步进行的.比如说在开发板上调试模块驱动,在其他平台上调试应用程序再移植到目前这个平台等. 嵌入式专栏 1 为 ...

  • 干货 | 嵌入式系统软件架构设计

    整理 :嵌入式云IOT技术圈,作者:veryarm 1. 前言 嵌入式是软件设计领域的一个分支,它自身的诸多特点决定了系统架构师的选择,同时它的一些问题又具有相当的通用性,可以推广到其他的领域. 提起 ...

  • 嵌入式软件架构设计之分层设计

    在实际的项目开发中,项目往往是并行开发的,也就是说硬件设计,底层软件设计,应用软件设计是同步进行的.比如说在开发板上调试模块驱动,在其他平台上调试应用再移植到目前这个平台等. 要想开发的应用程序在不同 ...

  • UC头条:软件架构设计

    一.软件架构设计 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素.元素的外部可见属性及它们之间的关系组成. 软件系统架构是关于软件系统的结构.行为和属性的高级抽象.指定了软件 ...