Complete the design of the automotive body control domain system based on enterprise architecture (EA) software

Domestic OEMs usually use text to describe system design in the functional development of body controllers. The dependencies between functions are not clear and the function reuse rate is not high. With the increase in the number of functional requirements, the industry has proposed a service-oriented automotive architecture (SOA) solution to improve the reuse rate of each function. This paper explores the SOA architecture design methodology, summarizes the practical experience of designing and developing the ambient light subsystem in the body control domain of the Lantu Automobile SOA platform, and explains how to use enterprise architecture (EA) software to complete the system design of the automobile body control domain, deliver development requirements documents and system function specifications, so as to achieve the purpose of improving design efficiency and quality.

0 Introduction

When the mainstream domestic vehicle manufacturers complete the design of the body control system or its related subsystems, they usually use Microsoft Visio software to draw the flow chart and carry out the design work, use Microsoft Word to manually write the text description of the functional specifications or subsystem specifications, and use Auto CAD tools to assist in the design of the system block diagram. With the introduction of the concept of "domain", compared with the early development of the functions of automobile body controller products, the body domain controller not only has an endless stream of new functions [1], but also has cross-reuse between functions. For example, a luxury car produced in 2010 has 800 vehicle functions [2], while in 2007 there were only 270 vehicle functions [3]. For example, in the two functional requirements of the central control screen controlling the window and voice controlling the window, the execution end (the part of the controller that drives the window lifting motor) has the same processing logic, and this part of the logic can be reused in different window control methods. With the increase in the cross-reuse between functions, it is increasingly difficult to sort out the functional links and the interactive relationships between functions when designing the system using text descriptions and some illustrations.

In the current era of software-defined cars[4], car manufacturers rely on architecture solutions to build cars in order to control costs, improve product competitiveness[5], and accelerate the iteration of software products. For example, Volkswagen Group's Modular Electrification Toolkit (MEB) architecture, Toyota New Global Architecture (TGNA) and Geely Auto's Sustainable Experience Architecture (SEA) architecture are all currently advanced service-oriented automotive architectures (SOA) in the world. These automotive architectures are characterized by coarse-grained and loose coupling. Services communicate with each other through simple and precise interfaces. The basic principles of their design are:

(1) Standardized service contracts;

(2) Loose coupling of services;

(3) Reusability of services;

(4) Service autonomy[6].

From this, it can be seen that when designing and outputting the functional specifications corresponding to the body control system or subsystem, under the new architectural scheme, system designers also need to standardize the definition of the service interface.

Under the new architecture, the developers of the vehicle body domain system use Enterprise Architect (EA) software to complete the subsystem design of the body domain[7], complete the writing of functional specifications and development deliverables, and conduct research on extended functional development based on the Application Program Interface (API) provided by EA. EA is an enterprise architecture software[8] that covers the entire system development cycle. In addition to developing class models, it also includes transaction process analysis, use case requirements, dynamic models, components and layout, system management, non-functional requirements, user interface design, testing and maintenance. EA users can also use the basic elements in EA to encapsulate a set of element plug-ins that meet usage requirements. Therefore, choosing to use EA for the design and development research of the body control domain subsystem has a high degree of flexibility and fit.

1 Modular hierarchical framework construction

To design the body control domain subsystem under the SOA architecture using EA, you first need to use EA to build the subsystem framework. In order to avoid unclear dependencies between related elements, there are usually two solutions for building the framework.

(1) Solution 1: Build a server based on a certain vehicle platform. Use unique numbers to identify functions in the server. New functional requirements are numbered in a new order. Solidified functional requirements will not be numbered again. All functional requirements on this vehicle platform are collected on one server. When developing different models, they are split and reorganized according to functional requirements to complete the functional design of the body domain subsystem and output functional specifications and development deliverables.

(2) Solution 2: Build servers based on projects. Each server is developed and maintained separately. This solution is more suitable for different models with the same functions and customized development according to different use case requirements. The construction of the EA architecture development environment can be selected according to the company's strategic needs.

Documents need to be built in layers within the project. The division of software layers is a way to implement loose coupling in the SOA architecture. Therefore, when building documents, we must not only consider the sequence of the development process horizontally, but also the layered implementation of the software vertically [9].

To use EA to build a modular hierarchical framework, you first need to establish a functional requirement document, which is the basis for the design of the body control domain subsystem. It is mainly used to store the functional description and functional use case flow chart in the design. In the sub-documents of the functional requirement document, the functions need to be divided into modules. The body control domain belongs to one of the modules. Other control systems of the whole vehicle can be divided into different modules according to functional categories. After the functional requirement document is established, it will be distributed to system engineers for processing and maintenance.

The second step is to establish other requirement documents. For example, functional safety requirement documents and system performance requirement documents can be distributed to functional safety engineers and system engineers for construction and maintenance. Functional safety engineers guide software development based on functional safety goals; system engineers propose quantifiable and achievable performance indicators based on performance requirements, such as system resource usage and response time requirements.

Finally, establish a logical implementation document. The logical implementation document includes vertical software layering. The hierarchical classification of each domain module will be different. The body control domain is divided into software control layer, coordination layer, signal conversion layer, sensor and execution layer, and physical layer. This can be done by system engineers to design the corresponding external communication interface first, and then the software developers can define the internal interface according to the development requirements.

Based on the above description, the body control domain system design framework was built using EA, as shown in Figure 1.

Figure 1 Body control domain system design framework

2 Body Control Domain Subsystem Design

By following the following process in EA to carry out the design of the body control domain subsystem, the functional logic of the system can be presented very clearly, and logical confusion and unclear and ambiguous interface dependencies will not be caused during functional design, which objectively guarantees the quality of design and development.

2.1 Functional Requirements Document Content Design

The content of the functional requirement document includes functional description and functional use case flow.

2.1.1 Decompose functional requirements and complete functional description

After obtaining the system functional requirements of the body control domain, they should be decomposed. Decompose a function into multiple functional use cases, and express them with the Use Case element in EA. Consider the requirements to support the implementation of these functional use cases, the preconditions, trigger conditions, execution methods or steps of each functional use case, the expected execution results when other abnormal situations occur during the execution of the action, and the arbitration of information conflicts. All the information in these designs can be placed in different entries of the Use Case attribute in the form of text descriptions to complete the decomposition and definition of functional requirements.

2.1.2 Draw a functional use case flow chart

At this stage, we should first understand the distribution of each unit in the system based on the electronic and electrical architecture of the vehicle. Based on the physical unit and the software component as the carrier, we can abstract the product capability (PC) of the software component.

Drag the PC required for function implementation into each functional use case flowchart, and establish a specific association method in the "Operation" of the "Feature" tab. Now you can draw the transfer process of the functional flow, and on this basis, add the judgment conditions in the function definition to complete the functional use case flowchart design.