SOA automotive software development and deployment steps and interface description language conversion solution

SOA architecture is popular

With the advancement of the new four modernizations of automobiles, automobile manufacturers must not only achieve vehicle networking, autonomous driving and data-driven, but also quickly respond to customers' personalized needs on the basis of satisfying user experience and basic services. In order to better solve these new challenges, vehicle manufacturers have introduced high-performance chips and breakthrough technology products. At the same time, the traditional EE architecture also needs to be changed. SOA (service-oriented architecture) has become the preferred architecture for most vehicle manufacturers to respond to market demand. The main advantage of SOA architecture is that it can achieve decoupling between software modules of distributed systems to a large extent. Through software upgrade OTA, service entities can be deployed on any domain controller more conveniently and flexibly. Services only need to communicate through simple and precisely defined interfaces, without involving underlying programming interfaces and communication models. Moreover, the processes of ECU version update, signal library update, code modification, etc. are simpler and more flexible. It simplifies the registration of services and API calls, saves time costs, and improves the robustness and scalability of the system.

SOA Development and Deployment Steps

Designing and deploying a SOA automotive software can be roughly divided into the following steps:

Figure 1 SOA development and deployment steps

During the service interface development phase, it is often necessary to select scenarios with fixed rules, strong logic, and a large number of highly repeated scenarios for testing and verification. In order to quickly verify, architecture engineers usually use IDL (Interface Description Language) to describe the service definition as input for subsequent work on the development link. During the business logic development phase, services are implemented with unified standards. There are many IDL languages ​​on the market, such as FIDL, Protobuf, vCDL, ARXML, OMG IDL, CANoe FDX, etc. Testers need to start learning the syntax rules of various IDLs from scratch. The corresponding operations during the conversion process are also relatively complex and cumbersome, and the error rate is also high. If the software architecture adopts SOA and the functions in the system are service-oriented, the following scenarios will be encountered in the early technology selection, list definition, architecture design, and mid-term business logic development stages.

Scene 1

After using PREEvision Adaptive AUTOSAR to model the system and define service-related SWCs, architects usually export different types of ARXML, which defines the service interfaces, data types, parameter references, etc. These ARXML can be imported into CANoe for node simulation and Ethernet communication monitoring, and can also be imported into DaVinci IDE to generate code for development with DaVinci. However, this modeling process cannot be completed in the short term and requires constant communication and coordination. Considering convenience, the parties involved will use Excel as communication input during the communication process, and eventually convert the configuration information in Excel into ARXML and import it into related tools for verification.

Figure 2-1 Interface and data type definition Excel

Figure 2-2 Interface and data type definition Excel

As shown in the simple example above, structure references, data types and other information are prone to errors and often need to be repeatedly modified and reconverted into ARXML. This process is time-consuming and labor-intensive, and also affects the software development progress from an efficiency perspective.

Scenario 2

When testing Ethernet (taking SOME/IP as an example), developers output Excel files, and testers need to convert Excel files into a file format supported by the test software, such as vCDL. This step is extremely labor-intensive and the accuracy cannot be guaranteed.

Figure 3-1 Ethernet test interface definition Excel

Figure 3-2 Ethernet test interface definition Excel

Scene 3

When developers use DaVinci for architecture design, in order to speed up the development cycle, they usually use Excel as a template, fill in interface information, data types, SWC definitions, SWC and interface relationships, and then the module responsible person will use the data in Excel to make corresponding node configurations and connections in DaVinci Developer. The whole process has a high probability of error and high repetitiveness. A tool is needed to automatically generate ARXML files based on Excel template files to realize SWC conversion and the combination of interfaces and SWCs, so as to improve design efficiency.

Scene 4

In the SOA architecture, the application of middleware technology enables the decoupling of application software from the underlying operating system and hardware. We can use SIL (Software in loop) technology to verify the functionality of the system in the early stages of system development. An important part of SIL testing is SIL Adapter development. SIL Adapter implements the call of the tested service implementation by the test system. The SIL Adapter code structure for each service interface is the same, except for a small number of code differences in the number, name, and type of interface parameters. The entire process is also highly repetitive. A tool is needed that can automatically convert FIDL, XML, ARXML and other files produced by the architecture design into C++ and other codes, and can automatically generate stub code based on the description/remarks in the file, which will shorten the verification cycle.

Scene 5

During the SOA architecture design, test verification and other stages, engineers will use many configuration files as input or output files when using related tool software. However, due to the large number of tools used and the lack of unified standards between file formats, the various development tools and test tools used cannot support all formats. Therefore, the connection between the various tools is not smooth, which affects the work efficiency of engineers. A tool is needed to automatically convert these files of different formats to achieve efficient connection of tools.

Scene 6

Test cases are usually managed in Doors or Polarion. The test steps or test standards in the test cases are normally described in natural language. During the test execution, the software cannot recognize these descriptive languages. Testers need to convert these natural languages ​​into script files first, and then put the test scripts into the test project for execution. When there are many test cases, the workload will be very large. There is a need for tools that can integrate relevant case management software to automatically convert test cases into script files of the corresponding test software, thereby improving efficiency and reducing the probability of errors.

Scene 7

The SOA test development process generally requires the following steps:

1. Test specification development: Complete the development of test specifications based on requirement specifications, testing experience and understanding of implementation solutions.

2.SOA-HIL test system requirements analysis and test system development: pin and resource definition of the object under test, and establishment of HIL hardware and test software operating environment.

3. Test project development: Develop test projects to implement automated/semi-automated testing of test content defined in the test specifications.

4. Simulation model development: Develop a simulation model and establish an interface interaction with the node to be tested.

5. Test environment integration debugging and test execution: Test environment construction, engineering integration debugging and test execution for a specific object under test.

There are many types of input objects required in each of the above steps, such as: SOA function requirement specifications, service interface specifications, resource definition files, test scope definitions, ARXML and other type database files, test system third-party programming scripts, test specifications, communication databases, communication matrix files, tested node interaction data format definitions, etc. A tool is needed to uniformly classify and manage test items, and at the same time support format conversion between related input objects. The converted results can be easily loaded into related test software or can be automatically uploaded to the corresponding location of the configuration library through the network to facilitate subsequent operations.

Scene 8

Currently, SOA architecture software is generally managed using agile development methods. The high-frequency iteration of software versions greatly tests the workload and automated testing capabilities of testers. Currently, most vehicle manufacturers and parts suppliers are basically conducting or developing continuous integration testing solutions to solve this problem.

As shown in the figure below, with the prevalence of SOA architecture, input objects or specification files have become diversified. However, the prerequisite for the promotion of continuous integration testing is that the interface files or use case files that are not recognizable by these test software need to be converted into specification scripts that conform to the definition of the test software in advance, and can be integrated with related tools for automatic conversion.

Figure 4 Schematic diagram of continuous integration test file conversion requirements

Why is interface description language conversion needed?

The above scenarios all require testers to manually enter or convert data before they can continue to advance the project progress. This link is particularly critical, but the conversion cycle is often long, and the work is time-consuming and laborious, with a high error rate, resulting in frequent rework. These problems have always plagued developers/testers.