Interpretation 1 of "Vehicle SOA Software Architecture Technical Specifications 1.0": Overview of SOA architecture technology and current status of technical specifications
Latest update time：2021-06-22
Reads：
background:
"Vehicle SOA Software
Architecture Technical Specification 1.0" is the first vehicle SOA software architecture technical specification written by AUTOSEMO. It is the first theoretical system for SOA software architecture in the automotive industry. In the near future, AUTOSEMO will organize an official interpretation of this specification. Interested friends can follow the "
AUTOSEMO
" public account for more information.
This specification is based on the AUTOSEMO platform to conduct research on common technologies of vehicle SOA software architecture, as well as research and customization of developmental vehicle SOA architecture specifications. Share industry technologies and specifications to reduce disordered and repetitive development in the industry, save R&D costs, and maximize the benefits of industrial investment.
As the first version of the SOA architecture specification in the automotive field, this specification focuses on industry exchange
and learning of SOA technology to achieve the dissemination of SOA culture and the unification of industry cognition.
This specification
explores the development path of vehicle software architecture technical specifications
from the two technical fields of SOA architecture technology and AUTOSAR
technical specifications.
The main content of "Vehicle SOA Software Architecture Technical Specification 1.0" has a total of 4 parts and contains a lot of content. We will explain it in detail in multiple chapters. This article will introduce the first two chapters. The picture below is the directory:
01
SOA architecture technology overview
1.1 The purpose and value of service-oriented computing
The seven strategic goals of service-oriented computing are interrelated and can be divided into two groups, namely strategic goals
and strategic value (advantages).
Among them, improving organizational business agility, increasing return on investment and reducing R&D costs (or IT burden) are the values and advantages brought by the realization of the other four goals.
A set of strategic goals and benefits ( shown in Figure 1) collectively represent the goal state we aspire to achieve
when continuously applying service orientation to software program design
.
Understanding these goals and benefits is extremely beneficial because they provide us with the ongoing overarching context and rationale for sustaining our investment in achieving service orientation over the long term.
The following is a brief explanation of the connotations of the seven strategic goals:
1. Enhance intrinsic interoperability: Interoperability refers to the sharing of data. The more
interoperable
software programs are
, the easier it is to exchange information between them.
2. Enhanced federation: that is, federation of services. Software resources and applications are federated while
maintaining
their respective autonomy and autonomy.
3. Increase supplier diversification options: Supplier diversification capabilities mean that organizations must choose the “best
variety” of supplier products and technological innovations.
4. Simultaneously improve business and technology areas: that is, the design and implementation of applications must not only meet
initial
business needs, but also meet future business needs as the nature and direction of the business change.
5. Improve ROI: Measuring the return on investment (ROI) of an automation solution is
a key factor in determining the actual cost-effectiveness of an application or system.
6. Improve the organization's business agility: that is, the efficiency with which the organization can respond to changes to adapt
to
industry changes and outperform competitors.
7. Reduce R&D costs (IT costs): that is, reduce waste and redundancy, reduce scale and operating
costs
, and reduce expenses related to its governance and evolution, etc.
1.2 SOA architecture characteristics, advantages and disadvantages
SOA is a componentized model that connects different functional units (services) of an application through good interfaces and contracts between these
services
.
Among them, Service is a coarse-grained,
discoverable software entity that exists as a single instance and interacts with other applications or services through a set of loosely coupled and message-based models.
Interfaces are defined in a neutral way, independent of the hardware platform, operating system and programming language on which the service is implemented, so that services built in such a system can interact in a unified and universal way.
The interactive service is roughly composed of three entities: service requester, service provider and service registry.
The operations between entities include:
service publishing, service discovery, service binding and invocation.
Service-oriented architecture is one of many software architecture styles and a type of microservice architecture.
Because the service-oriented architecture style has the advantages of being based on standards, loose coupling, shared services, and coarse-grainedness, it is easy to integrate existing systems, has a standardized architecture, improves development efficiency, and reduces development and maintenance complexity, and is more in line with the intelligent network. In the connected era, in-vehicle systems have requirements for software architecture, so they have been introduced and adopted by the automotive industry.
SOA has its own advantages and disadvantages due to its componentization and service-oriented model characteristics. The specific analysis is as follows (only
for
the business characteristics and implementation environment of the IT industry):
Advantage analysis:
-
Flexibility to rearrange services or applications as needs change
-
Reuse of IT assets
-
Make the enterprise's information construction truly centered on business or application, and business personnel arrange services according to needs without considering technical details.
Disadvantage analysis:
-
Service partitioning is difficult
-
Are services orchestrated appropriately?
-
If there is a problem with the selected interface standard, it will bring additional overhead and instability to the system.
-
It is not possible to reuse IT hardware assets.
-
The mainstream implementation methods have many interfaces and are difficult to unify.
-
Mainstream implementation methods are limited to sharing services without interfaces
1.3 Current status of SOA technology application at home and abroad
In the IT industry, the SOA idea was first proposed by Gartner abroad in 1996. SOA
began to be promoted and popularized in 2005. In 2007, application manufacturers hoped to promote the implementation of SOA by publishing standards, such as SCA and SDO passing OASIS audit, WS-POLICY , W3C became W3C standards, etc. Today, SOA is widely and systematically used in foreign IT industries, communications industries, and government departments.
Among them, the key task of implementing SOA architecture in Europe and the United States is
to extract and package functions in existing systems to form standardized "services".
在国内，2006年之前是技术萌芽；2006-2008年是过热期；2009年度过了
幻灭期；
从2010年开始进入复苏期，现在正处于由复苏期迈向成熟期。
其中，国
内近30年的IT建设多为生产型系统，服务型系统普遍未开始建设，大量"服务"需要全新标准化构造。
在汽车行业，因汽车智能化和网联化需求，尤其是自动驾驶系统研发应用的
需要，车载系统SOA软件架构技术受到国内外整车企业的关注。
国外，2010年以宝马、电装、大众等为首的欧、美、日汽车产业巨头便开始车载SOA软件架构的研究工作，形成一定理论基础和实践成果，并对传统汽车电子系统进行革命性创新。
当前，大众、奥迪、宝马、福特等汽车巨头自成联盟，进行SOA软件架构技术和规范的应用研究，预计2023前后将开始应用于量产车型。
国内，整车企业有加入和使用的意愿，但考虑软件架构规范核心实施技术不给予开放，后期产品技术和产品生态会高度依赖国外技术平台和标准规范，将会严重制约车企自身创新发展。
其中， 一汽、东风和上汽等部分头部OEM己意识到SOA软件架构的重要性，在寻找自主解决方案。
同时，软件架构技术属于行业共性技术，属于开发式共性平台，因国内缺少行业协同和协作机制，在共性平台和生态建设方面发展缓慢。
02
SOA技术规范现状
2.1 Web服务SOA相关技术规范概述
Web服务作为SOA架构技术发展的典型和成熟代表，其促进了SOA架构技术
的发展和推广，其标准体系的开发方式和开发内容对于车载SOA软件架构技术规
范开发具有深入的指导意义。
2. 1. 1技术标准组织
SOA架构的WEB服务相关的标准化组织主要有三家，分别为万维网联盟
(World Wide Web Consortium, W3C)、结构信息标准化促进组织(Organisation
for the Advancement of Structured Information Standards, OASIS)和Web
服务互操作组织(Web Service Interoperability Organisation,WS-I)
W3C是一个专注于开发基于Web的行业技术标准的国际联盟。它的使命是通
过开发协议和指导方针，确保万维网作为一种多功能媒体的长期增长，使万维网
充分发挥其潜力。
1994年Tim Berners-Lee创建了W3C,因为跨网络分割的风
险
变得越来越明显（特别是在多个版本的HTML同时工作时）。
从那时起，W3C就开
始优先开发核心的Web技术(HTML、XML等），以及相关的样式化语言(CSS 、XSLT
等）。
如今，Web服务严重依赖于W3C开发的技术，W3C委员会制作Web服务技术
主要由以下几部分：
• XML 架构1.0;
• WSDL 1.1， 2.0;
• SOAP 1.1, 1.2；
• WS-Addressing 1.0;
• WS-Policy 1.5;
OASIS
OASIS成立于1993年，是一家非营利性的国际协会，旨在开发、整合和推
厂包括Web服务、安全、商业事务、供应链、电子政务、互操作性等所需的标准。
OASIS对Web服务的贡献包括对UDDI(Universal Description Discovery and
Integration)规范的标准化，以及对WS-BPEL规范的标准化。
此外OASIS也推
出了诸如面向服务的架构参考模型和面向服务架构的相关规范等。
OASIS和W3C
不同，他的主要兴趣在于制定附加规范以及支持不同的行业，与应用领域的关系
更为密切。
WS-I
WS-I成立于2002年，其目的不是建立新的标准，而是旨在推动Web服务 的互操作性。 具体目包括三个方面：
-
为客户的网络服务应用提供实施指导 和培训；
-
促进跨平台、跨应用软件和跨程序语言的网络服务的一致和兼 容，并保证可靠兼容；
-
致力于使网络服务协同成为本行业共同遵守的准 则，以帮助客户在网络服务技术的选择上轻松决策，提高网络服务的应用范围 和水平，并确保网络服务技术的持续发展。
2. 1. 2技术标准的形成
标准如何被开发出来？
为了充分利用Web服务技术，最大潜力发掘其技术价值，理解将技术规范开
发为已批准的行业标准的过程是很重要的。
这一切都始于新技术的原创想法，当社区对这个想法有足够的兴趣时，W3C
就会举行一个开放的研讨会，相关方聚在一起讨论技术解决的范围和技术提出的
解决方案。
就Web服务而言，供应商组织通常倡议他们独立或合作开发的技术，虽然这
些技术常常用来解决那些对供应商来说很重要的问题，但人们希望让它们成为非
专有的Web服务框架的一部分。
如果W3C参与者之间有足够的协议，那么这些所
提出的技术将成为创建行业标准的基础。
标准开发流程是怎样的？
The first step in the W3C technical specification declaration cycle is the establishment of a working group responsible for defining the target standard. This
group will be composed of W3C members, who typically consist of vendor representatives and practitioners.
W3C also provides supporting
technical staff to help ensure that the technology will fully complement other industry standards already developed.
The group then develops a specification through the following stages:
l． Working Draft - This is a snapshot of the specification that is published periodically to keep the community informed of the direction the working group is
taking
and to gather early input.
2. Last Call Working Draft - When the working group feels that the specification meets all of its original requirements,
it will publish this document and formally request input from the community.
This step usually lasts at least three weeks.
3. Candidate Recommendation - After incorporating feedback from the previous phase, the working group calls for implementation of the specification to ensure that the specification
is actually implementable and interoperable.
4. Recommendation - Certification that the specification has been successfully implemented in an interoperable manner has been submitted to the W3C Advisory Committee for
approval
. This step will take at least four weeks.
5. Recommendations - Specifications are W3C recommendations, often referred to as "industry standards."
The duration of the entire process varies depending on the scope and complexity of the specification being developed.
From the moment a working group
is formed, it can take anywhere from 18 months to several years to submit a W3C recommendation.
During these
stages
, the public can comment on the technical specification being developed by submitting feedback to which the working group is obliged to respond
.
All communications between working group members and all working group deliverables are published as public access.
One peculiarity of the W3C is that its process is consensus-based, meaning that the entire working group
needs to agree on a solution before a decision can be made.
Ballots
are only held in cases of serious disagreement
, and any decision taken via a vote is usually scrutinized for the remainder of the process.
2.2 Overview of AUTOSAR-AP platform SOA related technical specifications
The AUTOSAR-AP platform adopts SOA methodology and mainly involves the development of an adaptive software product.
It is a
complex workflow
including software analysis, design, development and deployment
.
It mainly includes two
aspects
:
workflow definition and outcome definition (Figure 2-2).
The specific description is as follows:
2.21 Process definition
As an extension of the CP platform, the methodology of the AP platform introduces new concepts.
Instances
are executed in the context of the process.
The AP platform introduces the concept of "machine",
which is a virtualized ECU, an entity that can deploy software.
It can
be
the AP software runs on a specific "machine".
(1)Develop service interface (Service Interface)
The AP platform is a service-oriented software architecture (SOA). Software development based on the AP platform first
requires the design of service interfaces.
The service interface can be composed of events, methods and
fields, and is the basis for generating software component header files.
(2)Develop communication structure (Communication Structure)
The OEM needs to specify the communication structure of the expected "machine" and the corresponding
configuration
, including all network endpoints and service discovery address ports of the machine.
This step will produce a
deliverable "Machine Design", and a specific "Machine" model will reference a
specific
"Machine Design" model.
(3) Develop adaptive application software (Adaptive Application Software)
Adaptive application software development starts with the design of software components (SW components). Software components are
defined through their ports, and each port implements a service interface.
Based on the service interface description,
a header file containing the implemented software component is generated.
Developers implement the core functionality of software components on this basis.
(4) Develop adaptive platform software (Adaptive Platform Software)
Similar to application-level software, platform-level software can be composed of software components based on standardized service interfaces,
or can be implemented directly without the need for software component models.
(5) Define and configure the machine
It includes the definition of functional group status and each status timeout, the mapping of processes to specific machines, and the configuration of
platform
services (such as NM, DoIP) and basic modules (such as logs).
This process produces a machine manifest that
is independent of
the service instance or application.
(6)Integrated software
After the software is implemented and compiled, it needs to be integrated into an executable file (CExecutable).
The instantiation of an executable file on a specific machine is defined through a process. Each process generates an execution
manifest (
CExecution Manifest), which includes the process and its startup configuration.
(7) Define and configure service instance (Service Instance)
First deploy the service interface, then define an instance of the service interface, and decide whether to provide or
use
the service instance.
Secondly, we need to establish the mapping of service instances to machines and the mapping of service instances to ports.
This process generates a Service Instance Manifest of all service instances required by the process
(8) Generate software package (Software Package)
Consolidate the executable file and the required manifest into a software package and upload it to the machine without re-flashing. OEMs
can store software packages in back-end servers for unified management.
2.22 Definition of results
Since the AUTOSAR workflow includes the entire automotive software development process and involves multiple development roles,
information interaction between each development role is required. In order to ensure that the information is not ambiguous, the work product rules of
each reviewed. definition.
At the same time, in order to meet the requirements of information preservation, transmission, and interaction,
it is necessary to define the carrier of these results. ARXML is the carrier that defines the results of different processes.
Different to represent different information and processes. The definition of these tags is AUTOSAR. The data element model
(as shown below).
MO:
Runnable software entities generated using M1-level rules, such as autonomous
software
Ml:
Use M2 level rules to define software components, such as door control software components.
The expression form of software components can be ARXML, C/C++ language or various documents.
Generally, a
tool
define the framework of the software component in the form of ARXML, and then imported into the downstream tool chain to generate
the target language.
Or directly generate the target language framework, and then complete the overall
software
;
M2:
Use M3 level rules to define elements, syntax and rules developed using AUTOSAR, such as
software components, ports, machines, lists, etc.
Elements at this level have nothing to do with specific functions and
are similar to the syntax of various development languages;
M3:
Metamodel used to define M2
The above is the content of the first two chapters, the following content will be shared in the next issue!
▼
This release
"Vehicle SOA Software Architecture Technical Specification 1.0"
If you want to know more, please scan the code
Inquiry: autosemo-info@caam.org.cn
京公网安备 11010802033920号