SOA architecture/test phase interface description language conversion solution

Latest update time：2022-06-10

Reads：

SOA architecture prevails

With the advancement of the new four modernizations of automobiles, automobile manufacturers must not only realize vehicle connectivity, autonomous driving and data-driven, but also quickly respond to the personalized needs of customers on the basis of satisfying user experience and basic services, for a better To effectively solve these new challenges, OEMs have introduced high-performance chips and breakthrough technology products. At the same time, the traditional EE architecture also needs to be reformed. SOA (service-oriented architecture) has become the preferred architecture for most OEMs to respond to market needs. . The main advantage of the SOA architecture is that it can achieve decoupling between distributed system software modules to a large extent. Through software upgrade OTA, service entities can be more conveniently and flexibly deployed on any domain controller, and services only need to be Simple and precisely defined interfaces for communication, without involving underlying programming interfaces and communication models. Moreover, the process of ECU version update, signal library update, code modification, etc. is simpler and more flexible. It simplifies registering services and calling APIs, saving time and cost, and improving the robustness and scalability of the system.

SOA development and deployment steps

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

Figure 1 SOA development and deployment steps

The service interface development phase often requires the selection of fixed rules, strong logic, and a large number of highly repetitive scenarios for testing and verification. In order to quickly verify, architecture engineers usually use IDL (Interface Description Language) to describe the service definition as a development tool. Input for subsequent work on the link, service implementation in the business logic development phase is based on 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 grammatical rules of various IDLs from scratch. The corresponding operations during the conversion process are also complicated and cumbersome, and the error rate is also high.

If the software architecture adopts SOA and the functions in the system are service-oriented, you will encounter several scenarios such as the following in the early technology selection, list definition, architecture design, and mid-term business logic development stages.

scene one

After architects use PREEvision Adaptive AUTOSAR to model the system and define service-related SWC, they usually export different types of ARXML. This file defines each service interface, data type, parameter reference, etc. These AP ARXML can be imported into CANoe for processing. Node simulation and monitoring of Ethernet communication also support importing DaVinci IDE to generate code and cooperate with DaVinci for development. However, this modeling process cannot be completed in the short term. It requires constant communication and coordination, and convenience is considered. During the communication process, relevant parties will use Excel as communication input, and eventually the configuration information in Excel will be converted into ARXML and imported into the relevant database. Verify using the tool.

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, information such as structure references and data types are prone to errors and often need to be modified repeatedly and then converted back to ARXML. This process is time-consuming and labor-intensive, and also affects the progress of software development from an efficiency perspective.

Scene 2

When testing Ethernet (taking SOME/IP as an example), the developer outputs Excel, and the tester needs to convert the Excel into a file format that the test software can support, such as vCDL. This link requires a huge workload and the accuracy is not high. ensure.

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 the interface information, data types, SWC definitions, SWC and interface relationships and other information in Excel, and then use the module to The person in charge makes the corresponding node configuration and connection association of the data in Excel in DaVinci Developer. The whole process has a high probability of error and is highly repetitive. A tool is needed to automatically generate ARXML files based on the Excel template file to implement SWC conversion and interface. Work in conjunction with SWC to improve design efficiency.

Scene 4

In the SOA architecture, the application of middleware technology decouples application software from the underlying operating system and hardware. We can use SIL (Software in loop) technology to functionally verify the system in the early stages of system development. An important part of SIL testing is SIL Adapter development. SIL Adapter implements the test system's call to the service under test. The SIL Adapter code structure for each service interface is the same. There are only a few code differences in the number, name, and type of interface parameters. The whole process is also highly repetitive. Tools are needed that can automatically convert the FIDL, XML, and ARXML and other files are automatically converted into C++ and other codes, and instrumentation code can be automatically generated based on the descriptions/notes in the files, etc., which will shorten the verification cycle.

Scene 5

In the stages of SOA architecture design, testing and verification, etc., engineers will use many configuration files as input or output files when using related tool software. However, given that there are many tools used and the standards between file formats are not uniform, each used Development tools and testing tools cannot support all formats, so the connection between tools is not smooth, which affects the work efficiency of engineers. Tools are needed that can automatically convert files in different formats to each other 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 process, the software cannot recognize these descriptive languages. Testers need to convert these natural languages first. Convert it into a script file, and then put the test script into the test project for execution. When there are many test cases, the workload will be very huge. You need tools that can integrate relevant use case management software and automatically convert the test cases into corresponding Test software script files to improve efficiency while reducing the chance 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, HIL hardware and test software operating environment construction.

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

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

5. Test environment integrated debugging and test execution: Test environment construction, project integration debugging and test execution are carried out for a specific tested object.

There are many types of inputs 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 types of database files, test system third-party programming scripts, test specifications, communications Databases, communication matrix files, tested node interaction data format definitions, etc. need tools that can be unified and classified according to test items, and can also support format conversion between related input objects, and the converted results can be easily loaded into related tests. The software can automatically upload it to the corresponding location in the configuration library through the network to facilitate subsequent operations.

Scene 8

At present, SOA architecture software is generally managed using agile development methods. The high-frequency iteration of software versions has greatly tested the workload and automated testing capabilities of testers. At present, most OEMs and parts suppliers have basically carried out or are currently working on the project. Continuous integration testing solution to solve this problem.

As shown in the figure below, with the popularity of SOA architecture, input materials or specification files have become diversified. However, the prerequisite for continuous integration testing is that these interface files or use case files that are not recognized by the test software need to be converted in advance into conforming tests. Software-defined specification scripts and the ability to integrate 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 require testers to manually enter or convert before they can continue to promote the project progress. This link is particularly critical, but the conversion cycle is often long, the work is time-consuming and laborious, and the error rate is also high, resulting in frequent rework. These The problem has been plaguing the developers/testers.

PAVELINK .

Introduction to SOA-Converter

In response to the above problems, Beihui Information developed the interface description language conversion tool-PAVELINK.SOA-Converter.

PAVELINK.SOA-Converter is an IDL conversion tool developed based on Eclipse. It can realize batch conversion of commonly used IDL languages (FIDL, OMG IDL, Protobuf, vCDL, CANoe FDX, ARXML, etc.), such as FIDL to CANoe FDX, FIDL and Protobuf mutual conversion, and also supports convenient conversion of CANoe FDX directly through Protobuf. Conversion function, before conversion, you can customize the output directory, whether to ignore annotation information, whether to batch convert, whether to convert to multiple files, etc. according to user needs.

PAVELINK.SOA-Converter combines the test agent engine to perform automated regression testing, which can solve the communication problem of the entire link and shorten the test verification time.

Users generally use PAVELINK.SOA-Converter to achieve rapid conversion of files. Compared with manual conversion, it not only saves time and cost to a large extent, but also ensures the accuracy of conversion, improves the progress of development and testing, and effectively reduces the cost of Maintenance costs.

Figure 5 PAVELINK.SOA-Converter working diagram

The main functions are as follows

• Interface language converter: Through interface language conversion, the connection between tool chains in the software design and development process based on SOA architecture is realized.

• Interface language editor: By building a centralized one-stop editing environment for multiple interface languages, secondary editing and conversion of interface files can be achieved, while functions such as grammar verification, keyword prompts, and completion can be implemented.

• Command line converter: Provides a headless cross-platform command line tool that supports command line call conversion functions.

• Configuration library integration: Integrate the configuration library, automatically synchronize files, update reminders, and automatically convert source files into target files when they are updated.

• Open calling interface: Integrate with external tools through file stream monitoring to facilitate automated testing.

• Flexible expansion of plug-ins: Quickly implement new script language conversion through flexible expansion of plug-ins.

• SOA communication solution expansion: By interpreting the interface description language, it is automatically converted into server (Skeleton) and client (Proxy) framework codes, etc.

PAVELINK .

SOA-Converter Instructions for Use

PAVELINK.SOA-Converter is very convenient to use. In Eclipse, you only need to click the mouse or use simple commands to complete the conversion work.

PAVELINK

Eclipse plug-in conversion

Install the plug-in in Eclipse, select the file, right-click ->SOA-Converter->select the format type that needs to be converted.

Figure 6 PAVELINK.SOA-Converter graphical diagram

PAVELINK

command line conversion

Conversions can also be performed via commands.

Description of common parameters:

[-sf] Specifies the source file type for conversion.

[-tf] Specifies the file type generated after conversion.

[-sp] Specify the file or location to be converted.

[-d] Specifies the output location of the converted file.

[-dv] Ignore version verification.

Figure 7 PAVELINK.SOA-Converter command line diagram

PAVELINK

Example description

An OEM's service interface test project based on SOA architecture uses PAVELINK.SOA-Converter to convert FIDL to CANoe system variable XML to simplify the test verification process.

Figure 8 Example of converting FIDL to CANoe system variables

After the conversion is completed, follow the steps to directly import the converted XML file into CANoe, as shown below.

Figure 9 Example of importing the converted system variable XML file into CANoe software

CCU domain controller test specifications, script development and testing services, using PAVELINK.SOA-Converter to implement the FIDL to SOA function to implement server and client C++ code examples.

Figure 10 Schematic diagram of SOA communication implementation node

As shown in the figure above, call PAVELINK.SOA-Converter to convert the service interface file output by design tools such as PREEvision and generate the corresponding Proxy, Skeleton, and Stub codes.

Figure 11 Service interface file conversion C++ example diagram

A supplier's network-linked controller SOA function specification test and development project uses PAVELINK.SOA-Converter to implement Excel to ARXML, interface and SWC association examples

Figure 12 Excel template diagram

The content of ARXML after conversion is as follows:

Figure 13 ARXML screenshot

More features, please stay tuned

• IDL file editor supports real-time conversion, that is, previewing the conversion results while editing, keyword prompts, keyword highlighting, syntax error prompts, etc.;

• Network test template file customization and automated script generation;

• Test tool integration to automatically drive CANoe, ECU-TEST, dSPACE and other loading projects for execution ;

• Continuous testing integration, automatically triggering test verification execution after the service interface definition file is changed.

Latest articles about

■Understanding the OSI Model Using Logistics

■Talk about the controversy of the maximum load of 375 kg for new energy vehicles

■What is the car moose test?

■Live Preview | AUTOSAR SOME/IP Technology Interpretation

■AP AUTOSAR Hard-Core Technology (5): Diagnostic Management

■How much does it cost to customize an automotive-grade ECU?

■Live broadcast today | CAN XL International Seminar

■“Customers are not afraid, so what are you afraid of?” - Reflection on the value of static analysis of automotive software

■Detailed explanation of the control algorithm of the electromechanical brake system (EMB) - Taking Tongyu Automobile and Feige Intelligent as examples

■[Opening this week] SAE-AWC 2024 Automotive EEA Innovation Technology Forum | Free registration