CN112367233B - Vehicle network ECU communication method and device based on service-oriented architecture - Google Patents

Abstract

The invention provides a vehicle-mounted network ECU communication method and device based on a service-oriented architecture, which specifically comprise the following steps: the ECU based on the CAN protocol sends CAN signals to the service conversion ECU, and the service conversion ECU extracts effective data from the CAN signals and converts the effective data into service; the service provider establishes a service connection with a client for calling the service through a SOME/IP-SD protocol; when the client calls the service of the service provider to execute the preset task according to the requirement, the service management module arranged on the service provider monitors the behavior of the service during execution. The data signal conversion service generated by the CAN protocol is converted by the service conversion ECU, the service management module is arranged in the service execution process for supervision, and the service credible module is arranged for decision making, so that the problem that the traditional CAN protocol ECU and the vehicle-mounted Ethernet ECU utilize a service-oriented architecture for communication is solved, and the communication process CAN be ensured to be safe and reliable.

Description

Vehicle network ECU communication method and device based on service-oriented architecture

technical field

The present invention relates to the field of automobiles, and in particular, to a method and device for ECU communication in an in-vehicle network based on a service-oriented architecture.

Background technique

With the development of science and technology, modern automobiles are also moving towards the development of intelligence and networking along with the progress of science and technology. With the rapid development of processor computing power and hardware, the functions of the whole vehicle are becoming more and more powerful. In view of the demand for new functions such as ADAS technology, high-quality in-vehicle entertainment, and OTA remote upgrade, the network bandwidth requirements of ECUs have also shown explosive growth, which exceeds the capacity limit of traditional in-vehicle networks. In addition, in order to provide the functions of the whole vehicle, the number of on-board ECUs and the volume of data to be transmitted increase, and the ordinary CAN network can no longer meet the demand. Especially in the intelligent cockpit, functions such as assisted driving and unmanned driving require a lot of Large bandwidth, this kind of demand CAN-FD is also unable to meet. Therefore, in order to meet the demand for high bandwidth, in-vehicle Ethernet is introduced into the in-vehicle network due to its high bandwidth, low latency, and the ability to reduce the weight of the in-vehicle wiring harness. Although the in-vehicle Ethernet is introduced into the in-vehicle network, the traditional CAN network still has relatively great advantages, such as high real-time, long transmission distance, strong anti-electromagnetic interference ability, etc., coupled with the safety standards of the automotive industry to verify the new technology It will take a long time. At this stage, traditional CAN network-based ECUs and in-vehicle network-based ECUs will coexist in the in-vehicle network. At this stage, the ECUs that communicate with in-vehicle Ethernet use a service-oriented architecture for communication based on the AUTOSAR architecture, while the traditional ECUs based on CAN networks do not support this mode. The method of using the service-oriented architecture to communicate with the ECUs transmitted by Ethernet has become a bottleneck restricting the communication technology of the in-vehicle network.

SUMMARY OF THE INVENTION

The present invention provides a vehicle network ECU communication method based on a service-oriented architecture, which is characterized by at least including:

The ECU based on the CAN protocol sends the CAN signal to the service conversion ECU, and the service conversion ECU extracts the valid data from the CAN signal and converts the valid data into a service;

The service provider establishes and creates a service connection with the client calling the service based on the SOME/IP-SD protocol;

The service conversion ECU needs to judge whether the valid data has been converted into a service before converting the valid data into a service. If the valid data has not changed compared with the previous one and has been converted into a service, the conversion will be terminated. If the valid data has changed or has not been converted As a service, the effective data is converted into a service.

A vehicle network ECU communication method based on a service-oriented architecture, further, the CAN protocol stack in the service conversion ECU parses the CAN signal to extract valid data, and the service conversion module in the service conversion ECU converts the valid data according to the AUTOSAR architecture. The standard protocol converts valid data into services for clients to call;

The service provider and the client include an ECU based on the CAN protocol, an ECU based on the in-vehicle Ethernet protocol, and a service conversion ECU.

A vehicle-mounted network ECU communication method based on a service-oriented architecture, further, when a client invokes a service of a service provider to perform a preset task according to a requirement, a service management module arranged in the service provider monitors the behavior of the service during execution;

The service management module monitors the service to obtain preset events, and then encapsulates the preset events and the corresponding context, and sends them to the service trusted module set at the service provider.

A vehicle network ECU communication method based on a service-oriented architecture, further, the service management module monitors the ongoing behavior of the service and collects feedback information formed by the behavior process of the service execution to the service trusted module;

When the behavior of service execution is found to be malicious, the service management module suspends service execution, requests permission from the service trusted module and waits for a response from the service trusted module;

The service trusted module responds to the service trusted module and instructs the service management module to terminate the service execution or allow it to execute normally or correct the execution behavior of the service according to the preset policy.

A vehicle network ECU communication method based on a service-oriented architecture, further, after the client invokes the service, the client requests a session identifier from the service trusted module, and after the request is successful, the service trusted module will create a session, and the session will be responsible for The corresponding session feedback is collected, and the client and service management modules use the requested session ID to maintain the session and report the feedback to the service trust module.

A vehicle network ECU communication method based on a service-oriented architecture, further, after the client invokes the service, the client creates a request, adds the client identifier and the session representation as headers to the request, and invokes the service;

If the service invoked by the client calls another service while performing the task, the service management module intercepts the incoming request and extracts the client ID and session ID for further session feedback;

Session feedback includes: session identifier, metadata, current service, and service to be called by the current service;

Metadata includes additional contextual information.

A vehicle network ECU communication method based on a service-oriented architecture, further, after the call is completed, the client obtains a session report through the service trust module, and the session report at least includes the comprehensive trust value of the session and whether the service is executed. Set a strategy.

A vehicle network ECU communication method based on a service-oriented architecture, further, the preset strategy includes the credibility of the service execution behavior, the credibility is dynamically variable, and the calculation basis of the credibility at least includes: the actual execution of the service Execution history, service reputation, customer ratings.

A vehicle network ECU communication method based on a service-oriented architecture, further, the functions provided by the ECU based on the vehicle Ethernet protocol as a client to call the ECU based on the CAN protocol include: based on the vehicle Ethernet protocol, the ECU sends a message through the SOME/IP protocol. The request information is sent to the service conversion ECU to request to call the corresponding service converted by the ECU based on the CAN protocol, and the service conversion ECU starts the corresponding service after receiving the request;

After the service is started, a service conversion module is set in the service conversion ECU to extract the valid data of the service and send it to the corresponding CAN protocol-based ECU to perform preset tasks.

An in-vehicle network ECU communication device based on a service-oriented architecture, comprising: an ECU based on an in-vehicle Ethernet protocol, an ECU based on a CAN protocol, a service conversion ECU, and an in-vehicle Ethernet switch, wherein the ECU based on the CAN protocol and the service conversion ECU Connected, the service conversion ECU and the vehicle Ethernet ECU are connected through the vehicle Ethernet switch;

The ECU based on the CAN protocol sends the CAN signal to the service conversion ECU, and the service conversion ECU extracts the valid data from the CAN signal and converts the valid data into a service-oriented service.

An in-vehicle network ECU communication device based on a service-oriented architecture, further, the service conversion ECU includes: a CAN protocol stack, which is configured to parse a signal transmitted based on the CAN protocol and extract valid data from it or convert valid data into CAN the transmission signal of the protocol;

The service conversion module is configured to convert valid data into services based on the AUTOSAR standard or extract valid data from services;

The service conversion ECU needs to determine whether the valid data has been converted into a service before converting the valid data into a service-based service. If the valid data has not changed compared with the previous one and has been converted into a service, the conversion will be terminated. If the valid data occurs Changes or not converted into services, then convert valid data into services.

An in-vehicle network ECU communication device based on a service-oriented architecture, further, the service conversion ECU further includes: a service management module, configured to be responsible for monitoring the execution of services at runtime to detect malicious service calls or malicious data Leak; whenever a service call is about to be made, a feedback message will be sent to the service trusted module; when malicious behavior of the service is detected, it has the ability to stop executing the service and wait for a response from the service trusted module, which will indicate that the service call is blocked or restore it to normal execution;

The service trust module is configured to respond to the service management module through the execution of the preset policy according to the feedback message from the service conversion module; the service trust module includes a trust database for defining a trust database for analyzing the called service and after the called service is executed, according to the client's session request, a session report of the execution process of the service is formed and sent to the client.

An in-vehicle network ECU communication device based on a service-oriented architecture, further, the ECU of the in-vehicle Ethernet protocol includes a service management module, which is configured to be responsible for monitoring the execution of services at runtime to detect malicious service calls or malicious services. Data leakage; whenever a service call is about to be made, a feedback message will be sent to the service trusted module; when malicious behavior of the service is detected, it has the ability to stop executing the service and wait for a response from the service trusted module, and the response will indicate that the service call is blocked or restore it to normal execution;

The service trust module is configured to respond to the service management module through the execution of the preset policy according to the feedback message from the service conversion module; the service trust module includes a trust database for defining a trust database for analyzing the called service and after the called service is executed, according to the client's session request, a session report of the execution process of the service is formed and sent to the client.

An in-vehicle network ECU communication device based on a service-oriented architecture, further, a smart antenna is also set in the in-vehicle network, and the smart antenna is provided with a service configurator, an in-vehicle Ethernet protocol stack, and an external communication interface, wherein the service configurator Connected with vehicle Ethernet protocol stack and external communication interface;

The service configurator includes: a cache module for caching external information to handle the availability of the internal network.

Beneficial effects:

1. The present invention provides an on-board network ECU communication device under a service-oriented architecture, which can convert the signal transmitted based on the CAN protocol into a service to provide an on-board Ethernet-based ECU for invocation. At the same time, in the process of service invocation, the The execution behavior of the service is monitored. On the one hand, the communication between the traditional ECU and the ECU that implements the in-vehicle Ethernet is based on a service-oriented architecture. On the other hand, in the process of service execution, the existing service-oriented architecture lacks feedback and supervision in the service execution process, so that it can be applied to the in-vehicle network with security, real-time, and reliability. need.

2. When the service is converted, due to the periodic transmission of the CAN protocol signal, first determine whether the valid data extracted from the CAN signal has changed or has been converted into a service, and perform the corresponding operation according to the judgment result, not every time it is received. CAN signals all need to be converted, so that the internal resource consumption of the service conversion ECU is reduced. On the other hand, frequent service conversion will also lead to the continuous establishment of communication connections and message subscriptions between the service and the client, which will increase the load on the in-vehicle network and will seriously lead to the paralysis of the in-vehicle network.

Description of drawings

The following drawings merely illustrate and explain the present invention schematically, and do not limit the scope of the present invention.

FIG. 1 is a schematic structural diagram of an in-vehicle network under a service-oriented architecture according to an embodiment of the present invention.

FIG. 2 is a schematic structural diagram of a smart antenna according to an embodiment of the present invention.

FIG. 3 is a flow chart of converting a signal sent by an ECU based on a CAN protocol into a service through a service ECU in an embodiment of the present invention.

FIG. 4 is a flowchart of process monitoring in which a client invokes a service to perform a task according to an embodiment of the present invention.

Detailed ways

In order to have a clearer understanding of the technical features, objects and effects herein, specific embodiments of the present invention will now be described with reference to Figs. 1 to 4, in which the same reference numerals denote the same parts. For the sake of brevity of the drawings, the relevant parts of the present invention are schematically shown in each drawing, and do not represent the actual structure as a product. In addition, in order to make the drawings simple and easy to understand, in some drawings, only one of the components having the same structure or function is schematically shown, or only one of them is marked.

With regard to the control system, functional modules and application programs (APP) are well known to those skilled in the art, and can take any appropriate form, either hardware or software, a plurality of discretely set functional modules, or are multiple functional units integrated into one hardware. In the simplest form, the control system may be a controller, such as a combinational logic controller, a microprogram controller, etc., as long as the operations described in this application can be implemented. Of course, the control system can also be integrated into a physical device as different modules, which do not deviate from the basic principles and protection scope of the present invention.

In the present invention, "connection" may include direct connection, indirect connection, communication connection, and electrical connection, unless otherwise specified.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the present disclosure. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. It will also be understood that, when used in the specification, the terms "comprising" and/or "comprising" refer to the presence of stated features, values, steps, operations, elements and/or components, but do not exclude the presence of One or more other features, values, steps, operations, elements, components, and/or groups of components thereof are present or additionally added. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items

It should be understood that the terms "vehicle" or "vehicle's" or other similar terms as used herein generally include motor vehicles, such as passenger cars including sport utility vehicles (SUVs), buses, trucks, various commercial vehicles, Includes various boats, marine vessels, aircraft, etc., and includes hybrid vehicles, electric vehicles, pluggable hybrid electric vehicles, hydrogen-powered vehicles, and other alternative fuel vehicles (eg, fuels derived from energy sources other than petroleum). As mentioned herein, a hybrid vehicle is a vehicle having two or more power sources, such as both gasoline-powered and electric-powered vehicles.

Furthermore, the controller of the present disclosure may be embodied as a non-transitory computer readable medium on a computer readable medium containing executable program instructions to be executed by a processor, controller or the like. Examples of computer-readable media include, but are not limited to, ROM, RAM, compact disc (CD)-ROMs, magnetic tapes, floppy disks, flash drives, smart cards, and optical data storage devices. The computer readable recording medium can also be distributed in network coupled computer systems so that the computer readable medium is stored and executed in a distributed fashion, eg, through a telematics server or a controller area network (CAN) or vehicle Ethernet.

This implementation provides an in-vehicle network ECU communication device based on a service-oriented architecture, see FIG. 1 , which specifically includes: an ECU based on the CAN protocol, a service conversion ECU, an in-vehicle Ethernet ECU, and a T-box, wherein the ECU based on the CAN protocol Connected with the service conversion ECU, the service conversion ECU, the ECU of the vehicle Ethernet protocol, and the T-box are connected through the vehicle Ethernet switch;

Specifically, in the in-vehicle network, most of the traditional ECUs are based on the CAN protocol. Because the transmission based on the CAN protocol has real-time and reliability, and has low cost and has been verified for hundreds of years, it has the advantage of being difficult to replace. In addition, in order to meet the high-speed and low-body weight transmission of modern smart cars, it is difficult for the ECU of the traditional CAN protocol to meet the requirements. The ECU based on the in-vehicle Ethernet protocol can meet the requirements of high bandwidth and low wiring harness weight. However, because the car involves many ECUs, each ECU has different applications and needs, so the ECUs based on the CAN protocol and the ECUs based on the in-vehicle Ethernet coexist for a long time. However, the communication efficiency of the ECU based on the traditional CAN protocol is low. In order to improve the communication efficiency of the ECU in the in-vehicle network, a communication mechanism based on a service-oriented architecture is proposed and applied in the in-vehicle network, but it also brings many problems. , How the ECU based on CAN protocol communication and the ECU based on vehicle Ethernet communicate through the service-oriented architecture.

The service conversion ECU is configured to be used as a medium for mutual communication and conversion between the ECU based on the CAN protocol and the ECU based on the vehicle Ethernet protocol. The service conversion ECU includes: CAN protocol stack, service conversion module, service management module, service trusted module, Vehicle Ethernet protocol stack;

The CAN protocol stack is used to encode and encapsulate the signal according to the standard format of the CAN protocol and send it to the ECU based on the CAN protocol or decode the received signal conforming to the CAN protocol;

The service conversion module is used to extract valid data from the decoded CAN protocol signal and convert the valid data into services;

The service defined in this embodiment includes: one or more methods, one or more events, and a logical combination of one or more fields; the service can independently implement a certain function.

The service can also call the service. For example, suppose there are three services A1, A2, and A3. According to the prior definition, the implementation of the A1 service needs to call A2, and the implementation of the A2 call needs to call A3. Therefore, when the A1 service is called, A2 and A3 also need to be called. to call.

The service management module is responsible for monitoring the execution of services at runtime to detect malicious service calls or malicious data leakage; whenever a service call is about to be made, a feedback message is sent to the service trust module; when a service malicious behavior is detected , with the ability to stop executing the service and wait for the response returned from the service trusted module, the response will instruct to block the service call or restore it to normal execution;

The service trusted module is used for responding to the service management module through the execution of the preset policy according to the feedback message from the service transformation module; the service trusted module includes a trusted database for defining a trusted database for analyzing the execution behavior of the called service, And after the called service is executed, according to the session request of the client, the execution process of the service is formed into a session report and sent to the client;

The in-vehicle Ethernet protocol stack is used to encode and encapsulate the signal according to the standard format of the in-vehicle Ethernet protocol and then send it to the ECU based on the in-vehicle Ethernet protocol or decode the received signal conforming to the in-vehicle Ethernet protocol and send it to the application for processing. data processing.

The ECU of the in-vehicle Ethernet protocol includes a service management module, a service trusted module, and an in-vehicle Ethernet protocol stack;

The service management module is configured to be responsible for monitoring the execution of services at runtime to detect malicious service calls or malicious data leakage; whenever a service call is about to be made, a feedback message is sent to the service trusted module; when a service is detected In the case of malicious behavior, it has to stop the execution of the service and wait for the response returned from the service trusted module, and the response will instruct to block the service call or restore it to normal execution;

The service trust module is configured to respond to the service management module through the execution of the preset policy according to the feedback message from the service conversion module; the service trust module includes a trust database for defining a trust database for analyzing the called service and after the called service is executed, according to the client's session request, a session report of the execution process of the service is formed and sent to the client.

The in-vehicle Ethernet protocol stack is used to encode and encapsulate the signal according to the standard format of the in-vehicle Ethernet protocol and then send it to the ECU based on the in-vehicle Ethernet protocol or decode the received signal conforming to the in-vehicle Ethernet protocol and send it to the application for processing. data processing.

Specifically, the service trusted module can set up an ECU separately, and set up a dedicated ECU built-in service trusted module uniformly, but although the design method can save the system running resources in each ECU, it will increase the communication cost. Because every time the service is called, the signal needs to be transformed for many times to be transmitted to the service trusted module in the dedicated ECU through the vehicle network bus, which increases the load of the vehicle network. In order to solve this problem, the present embodiment is provided in an ECU that can provide services, but is not provided in an ECU based on the CAN protocol.

When defining the service function, based on the SOME/IP protocol, the message ID (message ID) of the service is defined, which includes the service ID (Service ID) and the method ID (Method ID), and the message ID is a 32-bit identifier. Used to identify the message, the message ID must uniquely identify the method or event of the service, the assignment of the message ID is up to the user, however, the message ID must be unique for the entire system, the message ID is compared with the CAN ID and should be passed through a similar process to process.

The service provided based on the SOME/IP protocol at least includes: the message ID corresponding to the CAN ID, the service ID, the instance ID, and the event group ID;

The message ID includes a service ID and a method ID.

The service ID and instance ID are used to provide services, discover services, and stop services when establishing a connection with the client, and the service ID and instance ID are used for SOME IP_SD messages.

In order to ensure that the service message ID is unique in the entire in-vehicle network system, there is a corresponding mapping table between CAN ID and message ID and a message ID mapping table in the ECU that provides the service. When the service is generated, first apply in the message ID mapping table. The message ID corresponding to the service, the system automatically assigns a message ID to the service from the unused message IDs in the message ID mapping table, and at the same time, broadcasts the currently used messages of other ECUs that provide services in the vehicle network node through the UDP protocol. ID, the ECU providing the service updates the internal message ID mapping table.

This implementation also provides a communication method for the vehicle network ECU based on a service-oriented architecture, see Figures 3 and 4, and specifically includes:

The ECU based on the CAN protocol sends the CAN signal to the service conversion ECU, and the service conversion ECU extracts the valid data from the CAN signal and converts the valid data into a service;

The service provider establishes and creates a service connection with the client calling the service based on the SOME/IP-SD protocol;

The service conversion ECU needs to judge whether the valid data has been converted into a service before converting the valid data into a service. If the valid data has not changed compared with the previous one and has been converted into a service, the conversion will be terminated. If the valid data has changed or has not been converted As a service, the effective data is converted into a service.

Specifically, the traditional ECU based on CAN bus transmission can be divided into three transmission modes: event type, periodic type and hybrid type in the body CAN network according to different trigger conditions;

In the event-based transfer mode, messages are sent in time as the type or data changes. The advantage of this type of message is that it takes up very little bus resources, but there may be missed sending. This kind of message is similar to the interruption of the network, and the frame used for fault diagnosis can be event type.

In periodic transmission mode, the type of message sent cyclically with a certain period of time. The time precision required for this type of message is generally less than 10%, which can ensure the reliability of the message as much as possible. If the period is too short, the bus load may be too large and the quality of the network will be affected. In designing a network, the following basic rules can be followed: if a frame's ID number is smaller, its priority is higher, and its period can be smaller. Frames used to monitor network status can be periodic.

In mixed transmission mode: event type and periodic type mixed type frame. Event messages send frames that change in real time, and periodic sending ensures message integrity. For example, a frame used to monitor external devices, if the parameters in the frame do not change, it will be sent periodically. If the parameters in the frame have changed, the frame will be sent as an event, and then re-timed and sent as a periodic frame.

Therefore, in this implementation, the transmission mode based on the CAN protocol adopts the mixed frame type of event type and periodic type for transmission, but it is rarely used for diagnosis transmission. In most cases, it is a periodic transmission mode, based on the CAN protocol. All ECUs are periodically sending message data in the CAN network, which will cause the service conversion ECU to continuously convert the periodic messages from the CAN protocol. On the one hand, it performs repeated conversion work. The system resources of the service conversion ECU are excessively consumed and cannot perform its essential work (acting as a communication medium with the vehicle Ethernet-based ECU and the CAN-based ECU). In order to solve this technical problem, each time the valid data sent by the ECU from the CAN protocol is extracted. It is not necessary to convert every time before the data, because the ECU of the CAN protocol sends CAN signals periodically. Therefore, before the conversion, it is realized to judge whether the valid data has been converted into a service or even though it has been converted into a service, but the valid data has changed. If the valid data has changed or has not been converted into a service, the valid data will be converted into a service. If the valid data has not changed or has been converted into a service, the conversion process will be terminated. By judging the valid data and deciding whether to convert it into a service, the load of the service conversion ECU can be greatly reduced, so that the service conversion ECU can work normally. On the other hand, the services provided can change dynamically.

Specifically, the transformation process of the service transformation ECU includes:

The CAN protocol stack in the service conversion ECU parses the CAN signal to extract valid data, and the service conversion module in the service conversion ECU converts the valid data into a service for the client to call according to the standard protocol based on the AUTOSAR architecture;

The service provider and the client include an ECU based on the CAN protocol, an ECU based on the in-vehicle Ethernet protocol, and a service conversion ECU.

Valid data includes at least CAN ID, payload data, and request information;

Specifically, the automotive industry has higher security than consumer electronics, such as the mobile phone industry and the Internet industry. When a service-oriented architecture is used for communication, the client and the service provider are relatively independent, and the client only needs to call If the service performs malicious behaviors, such as leaking private data, altering data and other behaviors that are dangerous to safe driving, it may lead to serious safety accidents. In order to strengthen the service In order to control the safety of the process of execution and reduce the risk, this embodiment designs the service management module and the service trust module to cooperate with each other, so as to solve the security problem based on the service-oriented architecture applied to the automobile. In addition, since the client invokes the service, the currently invoked service is trusted in time, but the invoked service may still invoke another service or multiple services during the execution process, and even the invoked service invokes other services again. The client is uncontrollable, so there is a great risk, and it is necessary to monitor and evaluate the security of the execution behavior during the service invocation process.

Specifically, referring to FIG. 4 , when the client invokes the service of the service provider to perform the preset task according to the requirements, the service management module arranged on the service provider monitors the behavior of the service during execution;

The service management module monitors the service to obtain preset events, and then encapsulates the preset events and the corresponding context, and sends them to the service trusted module set at the service provider.

The service management module monitors the ongoing behavior of the service and sends the feedback information formed in the process of collecting the behavior of the service execution to the service trust module;

When the behavior of service execution is found to be malicious, the service management module suspends service execution, requests permission from the service trusted module and waits for a response from the service trusted module;

The service trusted module responds to the service trusted module and instructs the service management module to terminate the service execution or allow it to execute normally or correct the execution behavior of the service according to the preset policy.

After the client calls the service, the client requests the session ID from the service trusted module. After the request is successful, the service trusted module will create a session, and the session will be responsible for collecting the corresponding session feedback. The client and the service management module use the requested session ID to maintain the session and report feedback to the service trusted module.

After the client calls the service, the client creates a request and adds the client ID and session representation as headers to the request, calling the service;

If the service invoked by the client calls another service while performing the task, the service management module intercepts the incoming request and extracts the client ID and session ID for further session feedback;

Session feedback includes: session identifier, metadata, current service, and service to be called by the current service;

Metadata includes additional contextual information;

After the call is completed, the client obtains the session report through the service trust module, and the session report includes at least the comprehensive trust value of the session and whether the preset policy is violated during service execution;

The preset policy includes the credibility of the service execution behavior, the credibility is dynamically variable, and the credibility is calculated based on the actual execution history of the service, service reputation, and customer ratings;

Service reputation includes feedback provided by other service users;

The traditional credibility is qualitative, and for a service, either a trusted service or an untrusted service is defined, but the functions involved in the in-vehicle network are more complex, and it is difficult to define a service as a trusted service or an untrusted service. Trust service, because even if it is defined as trusted service, if its service encounters interference or attack or unpredictable situation during the execution process, it may lead to malicious behavior, and even behavior that affects the safety of the vehicle body.

In order to solve this problem, this implementation adopts quantitative and dynamically adjustable calculation for the credibility of the service:

Another score for trustworthiness is the client score, which can dynamically change the service's score; the trust update mechanism can be based on client-defined policies.

The ECU based on the in-vehicle Ethernet protocol as a client needs to call the functions provided by the ECU based on the CAN protocol, which specifically includes: based on the in-vehicle Ethernet protocol, the ECU sends the request information to the service conversion ECU through the SOME/IP protocol, and requests to call the corresponding ECU conversion based on the CAN protocol. After receiving the request, the service conversion ECU starts the corresponding service;

After the service is started, a service conversion module is set in the service conversion ECU to extract the valid data of the service and send it to the corresponding CAN protocol-based ECU to perform preset tasks.

The ECU of the in-vehicle network needs to be connected to the server in the cloud or with external devices for diagnosis. Therefore, a smart antenna is also set in the in-vehicle network. See Figure 2 for details. The smart antenna is connected to the in-vehicle Ethernet switch. The smart antenna includes: a service configurator, a vehicle-mounted Ethernet protocol stack and an external communication interface, wherein the service configurator is connected with the vehicle-mounted Ethernet protocol stack and an external communication interface;

The service configurator includes:

The service conversion module extracts valid data after parsing the signals received from different protocols, and translates the extracted valid data into services;

A caching module for caching external information to handle the availability of the internal network;

A security management module for applying policies and enforcing service-level access control;

IoT IoT protocols, protocols used to communicate with external devices, protocols include: MQIT, CoAP, etc.;

The external communication interface is used to communicate with external devices.

Specifically, the method for the external device to communicate with the ECU of the in-vehicle network node according to the requirements includes:

The external device establishes a network connection with the smart antenna, including:

The external device sends an access connection request through the external communication interface of the smart antenna, and the external communication interface sends the request information to the security management module set in the service configurator, and the security management module judges the request information whether to allow the external device to access the in-vehicle network. request and feedback the information to the communication interface of the external device. If the access is approved, the connection between the external device and the smart antenna is established but the external device is not allowed to directly access other ECUs of the in-vehicle network node;

The services of external devices calling the nodes of the in-vehicle network include:

Send a signal to the service conversion module, the service conversion module parses the signal, extracts valid data and converts the service, and determines whether the service is a control type or a data type. If it is a control type application service, the application service serves as the client and the service provided for it. After the ECU establishes a communication connection, the corresponding service is called to implement the function execution of the target ECU; if it is a data type service, at this time, the service, as a service provider, needs to establish a connection with the client of the required service. After the client subscribes to the service , sending data directly to the client.

When the amount of data transmitted by external data is greater than the preset traffic threshold, for example, the user needs to turn on the vehicle host, watch movies, listen to music, download large files, upgrade GPS navigation, etc. It is very large, and the in-vehicle network adopts the transmission based on the SOME/IP protocol. Due to the limitation of the transmission data size of a single frame, large-traffic transmission will occupy more bandwidth. In order not to affect the low-latency and highly feasible functions in the in-vehicle network In the normal operation of the process, when the transmission traffic is greater than the preset threshold, the data transmitted by the external device is temporarily cached in the cache module, and the data is sorted according to the first in, first out, and the data is transmitted when the network load is idle.

The above are only preferred embodiments of the present invention, and the present invention is not limited to the above embodiments. Those skilled in the art can understand that the form in this embodiment is not limited to this, and the adjustable manner is not limited to this. It can be understood that other improvements and changes directly derived or thought of by those skilled in the art without departing from the basic idea of the present invention should be considered to be included within the protection scope of the present invention.

Claims (12)

1. a vehicle-mounted network ECU communication method based on a service-oriented architecture, is characterized in that, at least comprising: The ECU based on the CAN protocol sends the CAN signal to the service conversion ECU, and the service conversion ECU extracts the valid data from the CAN signal and converts the valid data into a service; The service provider establishes and creates a service connection with the client calling the service based on the SOME/IP-SD protocol; When the client invokes the service of the service provider to perform the preset task according to the demand, the service management module set in the service provider monitors the behavior of the service during execution; The service management module monitors the service to obtain the preset event, and then encapsulates the preset event and the corresponding context, and sends it to the service trusted module set at the service provider; After the client calls the service, the client requests the session ID from the service trusted module. After the request is successful, the service trusted module will create a session, and the session will be responsible for collecting the corresponding session feedback. The client and the service management module use the requested session ID to maintain the session and report feedback to the service trusted module. 2. The vehicle network ECU communication method based on the service-oriented architecture of claim 1, wherein the service conversion ECU needs to judge whether the valid data has been converted into a service before the valid data is converted into a service, and if the valid data is the same as before. If there is no change and it has been converted into a service, the conversion will be terminated. If the valid data has changed or has not been converted into a service, the valid data will be converted into a service; The CAN protocol stack in the service conversion ECU parses the CAN signal to extract valid data, and the service conversion module in the service conversion ECU converts the valid data into services according to the standard protocol based on the AUTOSAR architecture; The service provider and client include an ECU based on the CAN protocol, an ECU based on the in-vehicle Ethernet protocol, and a service conversion ECU. 3. The vehicle network ECU communication method based on a service-oriented architecture as claimed in claim 1, wherein the service management module monitors the behavior that the service is executing and collects the feedback information formed by the behavior process of the service execution and sends it to the service provider. letter module; When the behavior of service execution is found to be malicious, the service management module suspends service execution, requests permission from the service trusted module and waits for a response from the service trusted module; The service trusted module responds to the service trusted module and instructs the service management module to terminate the service execution or allow it to execute normally or correct the execution behavior of the service according to the preset policy. 4. The vehicle network ECU communication method based on a service-oriented architecture as claimed in claim 1, characterized in that, after the client invokes the service, the client creates a request, and adds the client identifier and the session representation to the request as a header , call the service; If the service invoked by the client calls another service while performing the task, the service management module intercepts the incoming request and extracts the client ID and session ID for further session feedback; Session feedback includes: session identifier, metadata, current service, and service to be called by the current service; Metadata includes additional contextual information. 5. The vehicle network ECU communication method based on a service-oriented architecture as claimed in claim 1, characterized in that, after the call is completed, the client obtains the session report through the service trusted module, and the session report at least includes the comprehensive trust value of the session and the Whether a preset policy was violated during service execution. 6. The vehicle-mounted network ECU communication method based on a service-oriented architecture according to claim 3, wherein the preset strategy includes the credibility of the service execution behavior, the credibility is dynamically variable, and the calculation basis of the credibility At a minimum: actual execution execution history of the service, service reputation, customer ratings. 7. the vehicle-mounted network ECU communication method based on the service-oriented architecture as claimed in claim 1, it is characterized in that, the function that the ECU based on the vehicle-mounted Ethernet protocol needs to call the ECU based on the CAN protocol as the client side comprises: based on the vehicle-mounted Ethernet protocol The ECU sends the request information to the service conversion ECU through the SOME/IP protocol to request to call the corresponding service converted by the ECU based on the CAN protocol, and the service conversion ECU starts the corresponding service after receiving the request; After the service is started, a service conversion module is set in the service conversion ECU to extract the valid data of the service and send it to the corresponding CAN protocol-based ECU to perform preset tasks. 8. An in-vehicle network ECU communication device based on a service-oriented architecture, characterized in that it comprises: an ECU based on an in-vehicle Ethernet protocol, an ECU based on a CAN protocol, a service conversion ECU, and an in-vehicle Ethernet switch, wherein, based on the CAN protocol The ECU is connected with the service conversion ECU, and the service conversion ECU and the vehicle Ethernet ECU are connected through the vehicle Ethernet switch; The ECU based on the CAN protocol sends the CAN signal to the service conversion ECU, and the service conversion ECU extracts the valid data from the CAN signal and converts the valid data into a service-oriented service; The service conversion ECU includes at least a service management module, wherein the service management module monitors the service to obtain a preset event, and then encapsulates the preset event and the corresponding context, and sends it to the service trusted module set in the service provider; After the client calls the service, the client requests the session ID from the service trusted module. After the request is successful, the service trusted module will create a session, and the session will be responsible for collecting the corresponding session feedback. The client and the service management module use the requested session ID to maintain the session and report feedback to the service trusted module. 9. The vehicle-mounted network ECU communication device based on a service-oriented architecture as claimed in claim 8, wherein the service conversion ECU further comprises: a CAN protocol stack, configured to parse the transmission signal based on the CAN protocol And extract valid data from it or convert valid data into the transmission signal of CAN protocol; The service conversion module is configured to convert valid data into services based on the AUTOSAR standard or extract valid data from services; The service conversion ECU needs to determine whether the valid data has been converted into a service before converting the valid data into a service-oriented service. If the valid data has not changed compared with the previous one and has been converted into a service, the conversion will be terminated. If the valid data occurs Changes or not converted into services, then convert valid data into services. 10 . The vehicle network ECU communication device based on a service-oriented architecture according to claim 8 , wherein the service management module is further configured to be responsible for monitoring the execution of services at runtime to detect malicious services. 11 . Call or malicious data leakage; whenever a service call is about to be made, a feedback message will be sent to the service trusted module; when malicious behavior of the service is detected, it has the ability to stop executing the service and wait for the response returned from the service trusted module, the response will indicate Block service calls or restore them to normal execution; The service trust module is configured to respond to the service management module through the execution of the preset policy according to the feedback message from the service conversion module; the service trust module includes a trust database for defining a trust database for analyzing the called service and after the called service is executed, according to the client's session request, a session report of the execution process of the service is formed and sent to the client. 11. A vehicle network ECU communication device based on a service-oriented architecture according to claim 8, wherein the ECU of the vehicle Ethernet protocol comprises a service management module, which is configured to be responsible for monitoring the execution of services at runtime In order to detect malicious service calls or malicious data leakage; whenever a service call is about to be made, a feedback message will be sent to the service trusted module; when a service malicious behavior is detected, it has the ability to stop executing the service and wait for the return from the service trusted module , the response will indicate that the service call is blocked or resumed to normal execution; The service trust module is configured to respond to the service management module through the execution of the preset policy according to the feedback message from the service conversion module; the service trust module includes a trust database for defining a trust database for analyzing the called service and after the called service is executed, according to the client's session request, a session report of the execution process of the service is formed and sent to the client. 12. A vehicle-mounted network ECU communication device based on a service-oriented architecture as claimed in claim 8, wherein the vehicle-mounted network is also provided with a smart antenna, and the smart antenna is provided with a service configurator, a vehicle-mounted Ethernet protocol stack, an external communication interface, wherein the service configurator is connected with the in-vehicle Ethernet protocol stack and the external communication interface; The service configurator includes: a cache module for caching external information to handle the availability of the internal network.

Images