CN119690400A - A solution for SOME/IP to DDS conversion - Google Patents

Abstract

The present invention proposes a solution for converting SOME/IP to DDS, by using CSV Parser and Model Parser in GenTool to read csv format input files and arxml models respectively, and using Generator in GenTool to convert the information extracted by Model Parser from SOME/IP elements to DDS elements, thereby generating DDS and SOME/IP codes respectively, and using TemplateRenderer to write DDS and SOME/IP codes into template through jinja template, and then generating the corresponding code of Application Project, and finally Integration Project combines the code generated by Application Project with AP library of Vector to generate the corresponding executable program, which is stored in the executable program folder generated by install, so as to realize the conversion of SOME/IP to DDS. The present invention solves the problems of incompatibility between SOME/IP and DDS protocols and differences in data model mapping.

Description

SOME/IP-to-DDS solution method

Technical Field

The invention relates to the technical fields of electronic information technology, automobile technology and communication, in particular to a solution method for converting SOME/IP into DDS.

Background

An open automotive architecture (Automotive Open System Architecture, AUTOSAR) was developed by german automotive manufacturers and automotive electronics suppliers at month 9 of 2003 to provide an open automotive electronics architecture (EEA) standard. The architecture can provide a basic function management for the embedded application of the automobile, and improves the standardization and intercommunication of the electronic products, components and software of the automobile. And reliable products are brought to the increasingly advanced and complex vehicle-mounted control system market, and the development cost of the automobile is reduced.

Automotive electronics and electrical architecture challenges for AUTOSAR include dramatic increases in functional code, increased diversity of hardware platforms, and more diverse development flows and file formats, which are brought about by rapid complications.

Based on the above challenges, AUTOSAR provides a unified solution whose architecture provides a reusable test platform, functional layer & base layer software, and methodology & tools. Therefore, the development cost can be reduced, and the software quality can be improved.

Adaptive AUTOSAR/AUTOSAR AP as an architecture part of AUTOSAR in SOC provides a service-based architecture. It has the following characteristics:

1. different services can be dynamically connected and used without the need for predefined interfaces and configurations.

2. The method can be run on a plurality of kinds of hardware platforms, and can also support multiple processes by utilizing the existing POSIX compatible software libraries and tools.

3. The parallel computing capacity of the multi-core processor can be fully utilized, and the performance and efficiency are improved.

As the most common automotive middleware solution in an AUTOSAR AP, SOME/IP provides a service oriented communication for devices of different sizes and operating systems.

As shown in fig. 1, unlike the signal-based communication method, SOME/IP is widely used in fields such as automotive electronics and industrial automation as a service-oriented middleware protocol, and is favored for its good scalability and service-oriented performance. The sender of the SOME/IP sends data only when needed by the receiver, which has the advantage that no unnecessary data is present on the bus, thus reducing the load. On the other hand, when SOME/IP is used for Service Oriented Architecture (SOA) communication, the whole SOA system can be modeled as AR ELEMENT defined in the AUTOSAR AP such as SERVICE INTERFACE, and new software is added to the system without worrying about compatibility with other software.

SOME/IP supports middleware functions of 1 serialization and deserialization, 2 service discovery, 3 message publishing and subscription, 4.UDP message segmentation, 5 remote procedure call (Remote Procedure Calls, RPC) and message passing.

The DDS protocol is distributed by OMG organization, is applied to software distributed communication, is a middleware communication protocol taking data as center, has higher extensible architecture and reliability, and can realize low-delay data connection. And eProsima provides an open source product FastDDS implemented in c++ on this basis.

As shown in fig. 2, the FastDDS levels include:

1. The application layer (APPlication) specifically deploys apps in code, using the hierarchy of FASTDDS API, and the ara: com module used here someip, interacting with the hierarchy of design.

FastDDS layer deployment domain, participtant, publisher & Subscriber, dataWriter & DATAREADER, TOPIC, and corresponding configuration schemes are designed for this at GenTool.

And the RTPS layer is a hierarchy where FastDDS transmission protocol RTPS is positioned, and is connected with the application layer and the transmission layer.

4. Transport layer (Transport) supports UDP, TCP, and shared memory.

The transmission and connection between elements in FastDDS layers is shown in fig. 3. Notably, a Quality of Service (QoS) is provided in each element, this parameter defining the rules and guarantees to be followed when exchanging data, reliability being reliability policy with QoS. It has two cases:

1. Using Best effect, DATAWRITER will not resend if a missing sample occurs, covering the old value.

2. With the use of the retransmission, DATAWRITER resends the data, overwriting the old with new data if a missing sample condition occurs. During this time, the piece of data generates a snapshot of the data, which is stored DATAWRITER HISTORY.

Depth is a history policy that uses QoS. The function of this parameter is to control the number of retransmission samples that can be kept in the history at most.

When FastDDS is used, in order to generate DDS topic data type, a Fast DDS-Gen java program is usually used, its input is the idl file, and the code is generated as follows.

1. If typedef is used to define a particular type, then. Cxx and. H files are generated, which are datatype for which idl is generated.

2. If new variables are defined on the already defined categories, then the suffixes. Cxx and. H are generated on a first step basis with PubSubTypes. These two file functions are serialization and de-serialization of variables, which typically use Fast DDS-Gen to generate the results of the operation as shown in FIG. 4.

The robotic operating system (Robot Operating System, ROS) is an open source robotic framework proposed by the university of stanford in 2007 that employs a distributed framework (nodes) that enables executable files to be individually designed and loosely coupled at runtime, characterized as follows:

1. sharing and distribution are achieved using processes of packages and stacks.

2. And a code storage library combined system is supported, and distributed collaboration can also be realized.

3. Language independence can be readily implemented in any modern programming language.

4. The test is convenient and the expansibility is improved.

ROS have both ROS1 and ROS2, differing by the use of the middleware layer. As shown in FIG. 5, ROS1 adopts a self-developed TCP/UDP mechanism of ROS organization, and a master of an application layer is used as a daemon to start first, and then other nodes are started. The disadvantages are two:

The master node must be up first and very unstable, and the program needs to be restarted whenever the master node is overloaded, which is very inconvenient.

2. The system overhead is overlarge, a data copying mechanism is used, and for a little larger data, the data is easy to overload and hang up, the ROS1 needs to be supported by always considering the program performance, and only Python 2 is supported.

While ROS2 takes the above problems into account, the master is eliminated, the problems are well solved after DDS is used, and FastDDS is taken as an intermediate for ROS 2.

ROS2 provides two data transmission modes, ROS2 provides two, topic and service, both of which are implemented by node. the transmission of topic is similar to the transmission of event in the AP, while the transmission of service is similar to method. node is then conceptually similar to SERVICE INTERFACE in AP and participant in FastDDS.

For application in the algorithm, ROS2 can do the following:

1. and support middleware functions such as publisher/subscriber, action, service.

2. The instructions rostopic, etc. may be used to monitor the topic, service, etc. in real time.

3. Data visualization analysis can be performed with rviz, or import scenarios can be modeled with gazebo, etc.

4. Support for interfacing to specific hardware, importation of ROS procedures.

5. Robot/real vehicle data may be recorded using rosbag and played.

For the current electronic automobile, the existing algorithm related to sensing and controlling is very dependent on a library owned by the ROS to realize functions of parameter adjustment, simulation and simulation, but for a real automobile, SOME/IP is more common as a communication protocol between the SOC and the MCU, and the ROS2 is FastDDS instead of SOMEIP, namely, when the SOME/IP is applied to the systems in the fields of automobile electronics, industrial automation and the like, the integration of the SOME/IP and a high-performance real-time data distribution system adopting the DDS standard cannot be directly compatible, so that a method is needed to be provided for transcribing real automobile data obtained by the SOME/IP into the ROS, thereby simulating the real automobile situation to carry out parameter adjustment.

Unfortunately, most of the AP products on the market are not added with DDS, and some of the AP products are still under development even though they have DDS functions. So a solution has been developed to convert SOME/IP to DDS, thereby helping the algorithm to tune the data.

Disclosure of Invention

The technical scheme of the invention solves the following problems:

1. The protocol incompatibility is that SOME/IP and DDS adopt different data encapsulation and transmission mechanisms, and cannot directly communicate, and a mechanism needs to be designed to bridge the two protocols, so that seamless conversion of data is ensured.

2. The data model mapping that the SOME/IP service-based architecture has significant difference with the DDS topic-based data publishing/subscribing model requires efficient mapping of SOME/IP service definition to DDS topic and data types to maintain consistency of data semantics.

3. System resource optimization-in the process of converting data types of different protocols, it is necessary to efficiently utilize system resources, avoiding unnecessary data copying and processing delays, so as to maintain efficient operation of the system.

4. The requirements of the project are embodied in the arxml model of the AUTOSAR AP, from which the communication details (such as services, methods, events, data type definitions, etc.) related to SOME/IP are extracted, which is a tedious and error-prone task.

The technical scheme of the invention provides a solution for converting SOME/IP into DDS, which comprises the following steps:

Input obtains arxml model and csv format Input file;

CSV PARSER in GenTool extracts relevant DDS information about service in the csv format input file, complements relevant participant parameters of the DDS, searches corresponding service, and writes the DDS parameters;

Reading a process corresponding to a service in a arxml Model by a Model Parser in GenTool, and locating the process and corresponding SOME/IP related information through the key words of the elements;

The Generator in GenTool converts the information extracted by the Model Parser from SOME/IP element to DDS element according to the information extracted by CSV PARSER and Model Parser, the codes of DDS and SOME/IP are generated respectively, TEMPLATERENDERER writes the codes of DDS and SOME/IP into the template through jinja template, and the codes corresponding to Application Project are regenerated;

application Project code generated by using a Generator and compiling;

Integration Project combines the code generated by Application Project with the AP library of the Vector to generate a corresponding executable program, and storing the executable program in an executable program folder generated by the installment so as to realize SOME/IP conversion to DDS.

Preferably, the arxml model includes each service-related event and method data structure for extraction by the model server as someip & DDS outgoing messages.

Preferably, the csv format input file includes conversion DDS related queue_size and resolution information.

Preferably, the Someip related information includes SERVICEINTERFACE and SERVICE INSTANCE.

Preferably, the AP library of the Vector comprises src-gen and AP SDK generated by DaVinci tool.

According to the technical scheme, CSV PARSER and Model Parser in GenTool are adopted to respectively read csv format input files and arxml models, a Generator in GenTool is adopted to convert information extracted by the Model Parser from SOME/IP elements to DDS elements, so that codes of the DDS and SOME/IP are respectively generated, the codes of the DDS and the SOME/IP are written into a template through a jinja template by TEMPLATERENDERER, codes corresponding to Application Project are regenerated, and finally Integration Project combines the codes generated by Application Project with an AP library of a Vector to generate corresponding executable programs and stores the executable programs in an executable program folder generated by the entity to realize conversion of the SOME/IP into the DDS. The technical scheme of the invention solves the problems of incompatibility of SOME/IP and DDS protocol, data model mapping difference and the like.

Drawings

FIG. 1 is a schematic diagram of a prior art SOME/IP communication scheme;

FIG. 2 is a schematic diagram of a hierarchy owned by prior art FastDDS;

FIG. 3 is a schematic diagram of transmission and connection between elements in FastDDS layers of the prior art;

FIG. 4 is a graphical representation of the results of prior art FastDDS-Gen program runs;

FIG. 5 is a schematic diagram comparing prior art ROS1 and ROS2 architectures;

Fig. 6 is a schematic diagram of architecture involved in a solution of SOME/IP to DDS provided in an embodiment of the present invention;

FIG. 7 is a schematic diagram of a class CSVPARSER according to an embodiment of the present invention;

FIG. 8 is a schematic view of the Generator-like composition provided in an embodiment of the present invention;

FIG. 9 is a schematic diagram of a class DdsGenerator according to an embodiment of the present invention;

Fig. 10 is a schematic diagram of SOME/IP data conversion according to an embodiment of the present invention.

Detailed Description

The application will be further illustrated with reference to specific examples. It is to be understood that these examples are illustrative of the present application and are not intended to limit the scope of the present application. Furthermore, it should be understood that various changes and modifications can be made by one skilled in the art after reading the teachings of the present application, and such equivalents are intended to fall within the scope of the application as defined in the appended claims.

The relevant terms and concepts presented in the present invention are shown in the following table.

The embodiment of the invention provides a solution for converting SOME/IP into DDS, which relates to a framework shown in figure 6, and specifically comprises the following steps:

Input consists of arxml model of Vector AP and csv format input file. Wherein:

(1) arxml have an event and method data structure associated with each service. These event and method are extracted by the model server as someip & DDS messages.

(2) The csv input is used to provide the queue_ size, reliability information needed to convert the DDS that the model does not contain.

GenTool consists of CSV PARSER, model Parser, and Generator. Wherein:

2.1, CSV PARSER parameters of participant required for DDS are complemented by artificially decided csv information. The player will write the DDS parameters by searching for the corresponding service.

2.2 Model Parser. This step reads arxml information, including SERVICEINTERFACE and SERVICE INSTANCE, by the element's key location process and corresponding Someip related information.

2.3, Generator writes information to template by jinja template method based on SOMEIP & DDS information extracted by CSV PARSER and Model Parser, and regenerates Application Project given code.

Approject is the folder that Vector AP uses for compilers. Wherein:

(1) Application Project code generated using a Generator and compiled.

(2) Integration Project is used to combine Application Project code and Vector AP library to generate corresponding executable program. The AP library of Vector comprises src-gen and AP SDK generated by DaVinci tool.

(3) And (3) instaling, namely generating a folder for storing executable programs, wherein the processes can be independently or jointly operated. Different corresponding messages may be transmitted after execution according to the code logic designed in Application Project.

GenTool consists of 3 parts, wherein CSVPARSER can extract relevant dds information in the csv file about services, modelParser can extract processes corresponding to the services in the model to perform a linking function, and a Generator uses CSVPARSER and ModelParser information as input to generate a corresponding file by using a jinja template. Class CSVPARSER composition is shown in figure 7.

CSVPARSER consists of 4 classes, class Mappings and class SRVMAPPINGS handle event and method respectively, and classes MappingInfo and SrvMappingInfo act to store the read CSV column into the corresponding variable.

The method for initializing the read CSV comprises the following steps:

1. The csv file is opened in the function burst_csv () of class Mappings, and each row in csv is read using the method of csv.reader ().

2. The first line (header) is extracted using next () and the new line is automatically deleted.

3. Reading each line in the CSV file, packing the header and each line into a tuple list by using zip (), then packing the element list into a dictionary by using dist (), and finally adding the element list into the list by using application (). The list is recalled.

4. The header information of the CSV is read as input to class MappingInfo, stored, and returned to class Mappings.

5. The line with service_name empty is culled using required_ mappings ().

6. The get_event_and_ mappings () is used to extract the event and the address of the row.

And reading arxml model information of the Vector AP according to the format of the AutoSAR official network document, including information such as Process model information, executable model information, components model information and the like, and checking whether the model is correct.

As a result, get_ intmed _model () returns a value of the following structure:

{'processes':[View_for{Process(xxx_process)->Executable(Executable(xxx_p rocess)->Components([Component(xxx_component)->Interfaces([Service(aaa_i nterface)->API({'events':[Event(bbbTopic)],′methods':[Method:cccMethod],′fields':[],'errors':set(),'ap_errors':set()})},'machines':[],′components':[],′errors':[]}.

The class Generator includes two parts, a code that generates someip and a code that generates dds, as shown in FIG. 8.

For code generation of someip, it is necessary to obtain someip event & method information that is read by get_ intmed _model () from arxml model of Vector AP back to the class Generator for use.

For dds code generation, class DDSGenerator is designed in the Generator to extract the relevant someip elements from the arxml model of Vector AP, convert to dds elements, and combine the information of csv to generate code.

And for class TEMPLATERENDERER, is used to read jinja the template generation code file.

After ModelParser has extracted the information of the arxml model element, the Generator mainly implements the following steps:

1. initializing a Generator, comprising:

(1) The output address is stored.

(2) The elements extracted by ModelParser are stored.

(3) Initialization DdsGenerator, templateRender, CSVPARSER.

(4) The location of the program is configured fastddsgen.

2. All files in the output address are emptied.

3. An output file is generated using interface render ().

There are two main classes, sender publisher and receiver subscnber, of class DDSGenerator, as shown in FIG. 9. The function of this block is to import DDSGenerator the model elements generated by ModelParser into a format suitable for DDS.

TEMPLATERENDER is mainly embodied in the render () of the Generator. Specifically, the following activities are included.

1. Idl is generated.

2. DDS DATA TYPE codes are generated.

3. DDS PARTICIPTANT codes are generated.

4. Someip code is generated.

5. A static code is generated.

The corresponding data type is detected by means of the interface provided by ModelParser for checking datatype, the interface being ViewManyperation. So that the data type is written into the template according to the maps of the different types of corresponding jinja templates.

The flow of generating dds and someip is similar to the principle of generating idl files, except that the process and the corresponding someip SERVICE INTERFACE definition are obtained directly through the interface get_si_mapping () at this time, and the information is used as input to be added into the well-defined cpp &. H template.

The implementation manner of SOME/IP To DDS is shown in FIG. 10, and key parts of SOME/IP To DDS after adding AP code are as follows:

1. initializing portions of dds elements

Someip messages on the required translation are obtained through CSVPARSER, along with the depth & resolution information required in the DDS. For other configurations related to Fast DDS, the default is kept. Whether to transmit as DATAWRITER or DATAREADER in DDS PARTICIPANT is determined by ModelParser whether the port for event/method in the current process is provided/required.

2. Transmitting FastDDS a message corresponding to someip event

For event of SOME/IP, the core is that when interface GETNEWSAMPLE () of R20-11 is used, someip event data needs to be obtained, and data information of someip event is extracted according to data format using interface ConvertToIdl (), written in empty DDS DATA TYPE defined in advance and sent through FastDDS fixed interface write ().

3. Transmitting FastDDS a message corresponding to someip method

Similarly, in the case of SOME/IP to DDS for method, one response is sent to the ros for the received method.

SOME/IP message storage structure to DDS message storage structure.

The scheme for converting the base type from someip format to dds format is specifically classified into the following cases:

Base type: direct assignment.

Vector-values of vector for previous DDS (if any) are cleared, checked for null, then the new null DDS DATATYPE size is converted to vector for someip, and memcpy (), bol is directly assigned for data types other than bol.

Array-directly assigned dds via each array element.

Enum, element and value values are assigned to enum of dds, respectively.

Map, map to which key and value values are assigned dds, respectively.

And 6, recursively reading members of the struct, judging the types of the members, converting according to the corresponding types, and integrating the converted types into dds values.

Claims (5)

1. The SOME/IP-to-DDS solution method is characterized by comprising the following steps:

Input obtains arxml model and csv format Input file;

CSV PARSER in GenTool extracts relevant DDS information about service in the csv format input file, complements relevant participant parameters of the DDS, searches corresponding service, and writes the DDS parameters;

Reading a process corresponding to a service in a arxml Model by a Model Parser in GenTool, and locating the process and corresponding SOME/IP related information through the key words of the elements;

The Generator in GenTool converts the information extracted by the Model Parser from SOME/IP element to DDS element according to the information extracted by CSV PARSER and Model Parser, the codes of DDS and SOME/IP are generated respectively, TEMPLATERENDERER writes the codes of DDS and SOME/IP into the template through jinja template, and the codes corresponding to Application Project are regenerated;

application Project code generated by using a Generator and compiling;

Integration Project combines the code generated by Application Project with the AP library of the Vector to generate a corresponding executable program, and storing the executable program in an executable program folder generated by the installment so as to realize SOME/IP conversion to DDS.

2. The SOME/IP ddS conversion solution of claim 1 wherein said arxml model includes per service related event and method data structures for extraction as someip & DDS sent messages by modelparser.

3. The method for resolving SOME/IP to DDS as recited in claim 1, wherein the csv format input file includes queue_size and resolution information associated with the converted DDS.

4. A SOME/IP to DDS solution as recited in claim 1, wherein said Someip related information includes SERVICEINTERFACE and SERVICE INSTANCE.

5. The SOME/IP ddS conversion solution of claim 1, wherein said Vector AP library includes the src-gen and AP SDK generated by DaVinci tool.