CN116938983A - Cross-platform automobile open system architecture, communication method thereof and vehicle-mounted computer - Google Patents

Abstract

The application relates to a cross-platform automobile open system architecture, a communication method thereof and a vehicle-mounted computer. The application can set the automobile open system architecture as a client and a server, wherein the client comprises a microcontroller abstract layer interface adapting module which comprises a far-end MCAL interface, the server comprises a microcontroller and a microcontroller abstract layer, and when the microcontroller abstract layer interface adapting module receives a microcontroller abstract layer calling request from a microcontroller upper logic module, the microcontroller abstract layer of the server is called through the far-end MCAL interface to provide corresponding microcontroller abstract layer interface service; the remote MCAL interface is a bottom layer driver of the client, interface calling centralized in an application layer is avoided, feedback speed is improved, the remote MCAL interface can be accessed to a microcontroller abstract layer of the server without complex protocol conversion, and development difficulty is reduced.

Description

Cross-platform automobile open system architecture, communication method thereof and vehicle-mounted computer

Technical Field

The application relates to the technical field of automobile open systems, in particular to a cross-platform automobile open system architecture, a communication method thereof and a vehicle-mounted computer.

Background

In the transition stage of the development of the whole vehicle electronic and electric architecture from a distributed controller to a domain controller and a multi-domain fusion direction, the whole vehicle low-middle-high-end controllers coexist and have dispersed functional logic. The utility model provides a service network architecture based on SOME/IP (service oriented extensible middleware based on internet protocol) that whole vehicle function developed, relates to the application functions of each aspect such as automobile body, power, cabin, amusement, advanced Driving Assistance System (ADAS), and the like, and only the quantity of atomic services has exceeded five hundred, and the combination service of the upper logic module of microcontroller abstraction layer, application service, and SOME software definition car workgroups atomic services that have not been standardized yet, quantity can be thousands, thereby leads to system engineer to need design a large amount of service communication matrixes, and the software development and verification work that involves each service instance in whole vehicle multicontroller, the development degree of difficulty increases exponentially with respect to traditional signal-based communication. For controllers with lower computational power or without Ethernet function, service-oriented network architecture deployment cannot be directly supported, and access can be achieved through complex protocol conversion.

Disclosure of Invention

Based on the above, it is necessary to provide a cross-platform open system architecture of an automobile, a communication method thereof, a vehicle-mounted computer and a storage medium thereof, which can avoid centralized interface call in an application layer, improve feedback speed, and access a microcontroller abstract layer of a server without complex protocol conversion, thereby reducing development difficulty.

In one aspect, a cross-platform automobile open system architecture is provided, including a client and a server;

the client comprises a microcontroller abstract layer interface adaptation module and a microcontroller upper layer logic module, wherein the microcontroller abstract layer interface adaptation module comprises a local MCAL interface and a remote MCAL interface;

the server comprises a microcontroller and a microcontroller abstract layer, and the microcontroller abstract layer is in communication connection with the remote MCAL interface;

when the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters; if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module; if not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

Furthermore, the microcontroller abstraction layer and the remote MCAL interface realize service communication connection through a service interface; the service interface realizes communication between the electronic devices in a communication protocol mode.

Further, when the service interface adopts a SOME/IP protocol based on a CAN transmission layer, the service interface comprises a client service data analysis module, a client CAN transmission layer, a server service data analysis module and a server CAN transmission layer.

Further, when the service interface adopts the SOME/IP protocol, the service interface includes a client SOME/IP conversion module, a client socket adaptation module, a client TCP/IP module, a server SOME/IP conversion module, a server socket adaptation module and a server TCP/IP module.

Further, the upper logic module of the microcontroller comprises an application layer, a runtime environment layer, a service layer, an electronic control unit abstract layer and a complex driving layer.

In another aspect, a communication method of the cross-platform automobile open system architecture is provided, which includes the steps:

controlling the interface adaptation module of the client-side microcontroller abstract layer to detect a microcontroller abstract layer call request from the upper logic module of the microcontroller in real time;

When the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters;

if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module;

if not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

Further, the step of transmitting the call request of the micro-controller abstraction layer to the micro-controller abstraction layer of the server through the remote MCAL interface and transmitting the execution result fed back by the server to the logic module of the micro-controller upper layer includes:

when the microcontroller upper logic module of the client side invokes the microcontroller abstract layer interface service of the server side, if the microcontroller abstract layer interface adaptation module identifies that the invocation belongs to remote invocation, the interface parameter is transmitted to a remote MCAL interface;

the remote MCAL interface sends a service call request for acquiring the interface of the abstract layer of the microcontroller to the service interface, and the service interface transmits the service call request for acquiring the interface of the abstract layer of the microcontroller to the service end and transmits a return value fed back by the service end to the upper logic module of the microcontroller.

Further, the remote MCAL interface sends a service call request for acquiring the interface of the microcontroller abstraction layer to the service interface, and the service interface transmits the service call request for acquiring the interface of the microcontroller abstraction layer to the service end and transmits a return value fed back by the service end to the upper logic module of the microcontroller, which comprises the following steps:

the service interface adopts a class SOME/IP protocol based on a CAN transmission layer, and transmits interface parameters in an interface service call request of an obtained microcontroller abstract layer to a client service data analysis module;

the client data service analysis module combines the service ID and the service parameter list into service data and transmits the service data to the client CAN transmission layer;

the client CAN transmission layer sends service data to the server CAN transmission layer through a CAN interface;

after the service end CAN transmission layer receives the service data, the service data is transmitted to a service end service data analysis module;

the server-side data analysis module analyzes a service ID and a service parameter list from the service data and calls a corresponding microcontroller abstract layer function to generate a return value;

the microcontroller abstract layer of the server transmits the return value to the service data analysis module;

The service data analysis module packs the returned values and transmits the packed values to the CAN transmission layer of the service end;

the CAN transmission layer of the server sends the return value to the CAN transmission layer of the client;

the client CAN transmission layer transmits the received data to the client service data analysis module;

the client service data analysis module strips a return value from data and provides the return value to the microcontroller abstract layer interface adaptation module of the client;

the microcontroller abstraction layer interface adaptation module of the client communicates a return value to the microcontroller upper layer logic module.

Further, the remote MCAL interface sends a service call request for acquiring the interface of the microcontroller abstraction layer to the service interface, and the service interface transmits the service call request for acquiring the interface of the microcontroller abstraction layer to the service end and transmits a return value fed back by the service end to the upper logic module of the microcontroller, which comprises the following steps:

the service interface adopts SOME/IP protocol to transmit interface parameters to the client SOME/IP conversion module;

the client SOME/IP conversion module sequences the service ID and the service parameter list to form a first data stream, and transmits the first data stream to the client socket adaptation module;

The client socket adapting module adds a header to the first data stream to form a first TCP/IP message which is transmitted to the transmission control protocol/Internet protocol module;

the client TCP/IP module sends a first TCP/IP message to the server TCP/IP module through an Ethernet interface;

the server TCP/IP module transmits the received first TCP/IP message to the server socket adapting module;

the server socket adapting module strips the header of the first TCP/IP message to obtain a first data stream and transmits the first data stream to the server SOME/IP conversion module;

the server SOME/IP conversion module deserializes the first data stream to obtain a service ID and a service parameter list, and calls a corresponding microcontroller abstraction layer function to generate a return value;

the microcontroller abstract layer of the server transmits the return value to the SOME/IP conversion module of the server;

the server-side SOME/IP conversion module sequences the return value to obtain a second data stream, and transmits the second data stream to the server-side socket adaptation module;

the server socket adapting module adds a header to the second data stream to form a second TCP/IP message which is transmitted to the server TCP/IP module;

the server-side TCP/IP module sends a second TCP/IP message to the client-side TCP/IP module;

The client TCP/IP module transmits the received second TCP/IP message to the client socket adapting module;

the client socket adapting module strips the header of a second TCP/IP message to obtain a second data stream and transmits the second data stream to the client SOME/IP conversion module;

the client SOME/IP conversion module deserializes the second data stream to obtain a return value and transmits the return value to the microcontroller abstract layer interface adaptation module of the client;

the microcontroller abstraction layer interface adaptation module of the client communicates a return value to the microcontroller upper layer logic module.

In yet another aspect, there is provided a vehicle-mounted computer comprising a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:

controlling the interface adaptation module of the client-side microcontroller abstract layer to detect a microcontroller abstract layer call request from the upper logic module of the microcontroller in real time;

when the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters;

If yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module;

if not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

According to the cross-platform automobile open system architecture, the communication method and the vehicle-mounted computer thereof, the automobile open system architecture is set to be a client and a server, the client comprises a microcontroller abstract layer interface adapting module, the microcontroller abstract layer interface adapting module comprises a far-end MCAL interface, the server comprises a microcontroller and a microcontroller abstract layer, and when the microcontroller abstract layer interface adapting module receives a microcontroller abstract layer calling request from a microcontroller upper logic module of the microcontroller, the microcontroller abstract layer of the server is called through the far-end MCAL interface to provide corresponding microcontroller abstract layer interface service; the remote MCAL interface is a bottom layer driver of the client, interface calling centralized in an application layer is avoided, feedback speed is improved, the remote MCAL interface can be accessed to a microcontroller abstract layer of the server without complex protocol conversion, and development difficulty is reduced.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for the description of the embodiments will be briefly described below, and it is apparent that the drawings in the following description are only some embodiments of the present application, and other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a block diagram of an existing open system architecture for an automobile;

FIG. 2 is a schematic diagram of a service interface connection mode implemented between existing open system architectures of an automobile through an application layer;

FIG. 3 is a block diagram of a cross-platform automotive open system architecture in accordance with one embodiment of the present application;

FIG. 4 is a schematic diagram of the service layer data protocol of SOME/IP in accordance with one embodiment of the application;

FIG. 5 is a flow chart of a communication method of a cross-platform vehicle open system architecture according to an embodiment of the application;

FIG. 6 is a flowchart illustrating steps of transferring a call request from a micro-controller abstract layer to a micro-controller abstract layer of the server through the remote MCAL interface, and transferring an execution result fed back by the server to an upper logic module of the micro-controller according to an embodiment of the present application;

Fig. 7 is a schematic diagram of a communication data flow of the MCAL interface service based on CANTP according to an embodiment of the present application;

fig. 8 is a schematic diagram of a communication data flow of MCAL interface service based on SOME/IP according to another embodiment of the present application;

FIG. 9 is a schematic diagram illustrating the configuration of interface coordination between a client and a plurality of servers according to an embodiment of the present application;

FIG. 10 is a schematic diagram illustrating a structure in which a client is accessed and connected by multiple servers according to an embodiment of the present application;

fig. 11 is an internal structural diagram of a vehicle-mounted computer according to an embodiment of the present application.

Detailed Description

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

AUTOSAR (AUTomotive Open System Architecture, automobile open System architecture) is a standardized software architecture for automobile ECUs. It is developed jointly by automobile manufacturers, suppliers and tool developers, aiming at creating a standardized software architecture for automobile ECU, thereby reducing development cost, improving software quality and realizing more efficient development flow. As shown in fig. 1, the AUTOSAR architecture is based on a hierarchy, each providing specific services and interfaces, including an application layer, a runtime environment, and a base software layer, which in turn is divided into: a service layer, an electronic control unit abstract layer, a microcontroller abstract layer and a complex driver.

As described in the background art, if the service layer is used to make an interface call to the abstract layer of the microcontroller, the process of processing in the application layer is further increased, so that the feedback speed is reduced due to concentration in the application layer. Typically, the microcontroller abstraction layer (MCAL) can only be used by the hardware abstraction layer of the local controller, as shown in fig. 1; and the service interface provides services based only on the whole vehicle application function, as shown in fig. 2.

And system engineers need to design a large number of service communication matrixes, and software development and verification work of each service instance in the whole vehicle multi-controller are involved, so that development difficulty is exponentially increased relative to traditional signal-based communication. For controllers with lower computational power or without Ethernet function, service-oriented network architecture deployment cannot be directly supported, and access can be achieved through complex protocol conversion. If a new vehicle model is involved, about 10% -50% of combined services and application services need to be redesigned and developed according to the function inheritance, so that additional development period and cost are required.

Based on the above, the application provides a cross-platform automobile open system architecture and a communication method thereof. At the server, the service interface which originally only provides the application function is sunk, the MCAL-based service interface is released through the network for the remote client to use, the abstract degree of the service is higher, and the reusability is stronger. And in the client, an MCAL interface adaptation layer is newly added, whether the MCAL request from an upper layer is a remote call is identified through the input interface parameters, if so, the call request is transmitted to a remote server, the execution result fed back by the server is transmitted to the upper layer, and if not, the local MCAL call is executed.

Among them, MCAL (Microcontroller Abstraction Layer ) is a programming interface for embedded software development. MCAL can serve as a programming interface so that developers can write portable code more conveniently. MCAL typically includes abstractions for four peripheral components, microcontroller, memory, communication, I/O. By using MCAL, developers can focus more on the development of applications without having to pay attention to the details of the underlying hardware.

In one embodiment, as shown in fig. 3, a cross-platform automobile open system architecture is provided, including a client and a server;

the client comprises a microcontroller abstract layer interface adaptation module and a microcontroller upper layer logic module, wherein the microcontroller abstract layer interface adaptation module comprises a local MCAL interface and a remote MCAL interface;

the server comprises a Microcontroller (Microcontroller) and a Microcontroller abstract layer (MCAL), wherein the Microcontroller abstract layer is in communication connection with the remote MCAL interface;

when the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters; if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module; if not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

Furthermore, the microcontroller abstraction layer and the remote MCAL interface realize service communication connection through a service interface; the service interface realizes communication between the electronic devices in a communication protocol mode.

Further, when the service interface adopts a SOME/IP protocol based on a CAN transmission layer, the service interface comprises a client service data analysis module, a client CAN transmission layer, a server service data analysis module and a server CAN transmission layer.

Among them, SOME/IP (Scalable Service-Oriented Middleware over IP, IP-based Service-oriented extensible middleware) is a relatively widely used automotive ECU (Electronic Control Unit ) software middleware solution. In a service oriented architecture, the sender sends data only when needed by the receiver. The advantage of this approach is that no excessive unnecessary data is present on the bus, thus reducing the load, but this is based on only one aspect of service communication. When talking about autopilot, ADAS, networked cars, etc., service Oriented Architecture (SOA) is essential. With the support of Ethernet and SOME/IP, the SOA models the entire system as a service interface, and new software can be easily added to the system without worrying about compatibility with other software.

The service layer data protocol of SOME/IP is shown in FIG. 4, in which the message ID is used to identify different services, unique to the same vehicle, with the first 16 bits being the service ID and the last 16 bits being the method ID; message length represents the sum of protocol version, interface version, message type, return code and message data length; the protocol version is iterated along with the update of the SOME/IP protocol, and is currently 1; updating iteration of the interface version according to the service version, and managing and maintaining the interface version by a service designer; message types can be classified into request, request non-response, event notification, response, error, etc., according to the specific application of the service; the return code is used for identifying whether the service request is successfully processed; message data is the content of service requests or responses, and the different services are very different and need to be defined in a service communication matrix.

Wherein CAN is an abbreviation for control unit area network (controlleraanetwork). The control unit exchanges data through the CAN network. The CAN transmission layer (CAN Transport Layer, CANTP) is a transmission layer positioned in the communication stack, is specially used for UDS diagnosis, is positioned between PDUR and CANIF, and realizes the unpacking and transmitting functions from PDUR to CANIF and the packet receiving functions from CANIF to PDUR.

The CAN-based communication transmission module of the CANTP (CAN Transport Layer, CAN transmission layer) is positioned at a service layer of the AUTOSAR architecture base software, and CAN transmit data with the length of more than 8 (CAN 2.0) or 64 (CANFD) on a CAN bus in a unpacking and packing mode.

Further, when the service interface adopts the SOME/IP protocol, the service interface includes a client SOME/IP conversion module, a client socket adaptation module, a client TCP/IP module, a server SOME/IP conversion module, a server socket adaptation module and a server TCP/IP module.

Wherein, TCP/IP (Transmission Control Protocol/Internet Protocol ) refers to a protocol cluster capable of implementing information transmission between multiple different networks. The TCP/IP transport protocol, the Transmission control/network protocol, is also known as the network communication protocol. The TCP/IP protocol refers not only to two protocols of TCP and IP but also to a protocol cluster composed of protocols of FTP, SMTP, TCP, UDP, IP and the like, and is called a TCP/IP protocol because the TCP protocol and the IP protocol are the most representative among the TCP/IP protocols.

Further, the upper logic module of the microcontroller comprises an application layer, a runtime environment layer, a service layer, an electronic control unit abstract layer and a complex driving layer. And the microcontroller abstract layer interface adapting module is a bottom layer driver of the client. The upper logic module of the microcontroller is the upper logic layer of the abstract layer of the microcontroller, namely an application layer, a runtime environment layer, a service layer, an abstract layer of an electronic control unit and a complex driving layer can initiate an instruction for calling an interface, and the instruction is changed into a call request of the abstract layer of the microcontroller.

In the above cross-platform automobile open system architecture, the automobile open system architecture is set as a client and a server, the client comprises a microcontroller abstract layer interface adapting module, the microcontroller abstract layer interface adapting module comprises a far-end MCAL interface, the server comprises a microcontroller and a microcontroller abstract layer, and when the microcontroller abstract layer interface adapting module receives a microcontroller abstract layer calling request from a microcontroller upper logic module, the microcontroller abstract layer of the server is called through the far-end MCAL interface to provide corresponding microcontroller abstract layer interface service; the remote MCAL interface is a bottom layer driver of the client, interface calling centralized in an application layer is avoided, feedback speed is improved, the remote MCAL interface can be accessed to a microcontroller abstract layer of the server without complex protocol conversion, and development difficulty is reduced.

The modules in the cross-platform automobile open system architecture can be implemented in whole or in part by software, hardware and combinations thereof. The modules can be embedded in the processor in the vehicle-mounted computer in a hardware mode or can be independent of the processor in the vehicle-mounted computer, and can also be stored in the memory in the vehicle-mounted computer in a software mode, so that the processor can call and execute the operations corresponding to the modules.

The communication method of the cross-platform automobile open system architecture provided by the application can be applied to an application environment shown in fig. 3.

In one embodiment, as shown in fig. 5, a communication method of a cross-platform automobile open system architecture is provided, which includes the following steps:

step S1, controlling the interface adaptation module of the client-side micro-controller abstraction layer to detect a micro-controller abstraction layer call request from an upper logic module of a micro-controller in real time;

step S2, when the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the upper logic module of the microcontroller, whether the call request is a far-end call or not is identified through interface parameters;

step S3, if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module;

and S4, if not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

According to the application, the automobile open system architecture is set as the client and the server, so that the interface coordination of the client and at least one server is realized, the microcontroller abstraction layer of the server can be accessed without complex protocol conversion, and the development difficulty is reduced. And the remote MCAL interface is the bottom drive of the client, so that interface calling centralized in an application layer is avoided, and the feedback speed is improved.

As shown in fig. 6, the steps of transferring the call request of the micro-controller abstraction layer to the micro-controller abstraction layer of the server through the remote MCAL interface and transferring the execution result fed back by the server to the logic module of the micro-controller upper layer include:

step S31, when the microcontroller upper logic module of the client side invokes the microcontroller abstract layer interface service of the server side, if the microcontroller abstract layer interface adaptation module identifies that the invocation belongs to remote invocation, the interface parameters are transmitted to a remote MCAL interface;

and step S32, the remote MCAL interface sends a service call request for acquiring the interface of the abstract layer of the microcontroller to the service interface, and the service interface transmits the service call request for acquiring the interface of the abstract layer of the microcontroller to the service end and transmits a return value fed back by the service end to the upper logic module of the microcontroller.

MCAL interface service CANTP (CAN transport layer) based communication data flow is shown in fig. 7.

Referring to fig. 7, the step of sending, by the remote MCAL interface, a service call request for obtaining a service of the interface of the abstract layer of the microcontroller to the service interface, and the step of sending, by the service interface, a return value fed back by the service end to the logic module of the upper layer of the microcontroller includes:

Step S101, the service interface adopts a class SOME/IP protocol based on a CAN transmission layer, and the interface parameters in the interface service call request of the obtained microcontroller abstract layer are transmitted to a client service data analysis module;

step S102, the client data service analysis module combines the service ID and the service parameter list into service data and transmits the service data to a client CAN transmission layer;

step S103, the client CAN transmission layer sends service data to the server CAN transmission layer through a CAN interface;

step S104, after the service data is received by the CAN transmission layer of the service end, the service data is transmitted to the service data analysis module of the service end;

step S105, the server data analysis module analyzes a service ID and a service parameter list from the service data, and calls a corresponding microcontroller abstract layer function to generate a return value;

step S106, the microcontroller abstract layer of the server transmits the return value to the service data analysis module;

step S107, the service data analysis module packs the return value and transmits the packed return value to the CAN transmission layer of the service end;

step S108, the CAN transmission layer of the server sends a return value to the CAN transmission layer of the client;

Step S109, the CAN transmission layer of the client transmits the received data to the service data analysis module of the client;

step S110, the client service data analysis module strips a return value from data and gives the return value to the micro-controller abstract layer interface adaptation module of the client;

in step S111, the interface adaptation module of the abstract layer of the microcontroller of the client transmits a return value to the upper logic module of the microcontroller.

The SOME/IP is a Scalable Service-Oriented Middleware over IP, and is based on an IP Service-oriented extensible middleware. IP refers to the acronym for internetworking protocol, internet Protocol, a network layer protocol in the TCP/IP architecture.

MCAL interface service the communication data flow based on SOME/IP is shown in fig. 8.

Referring to fig. 8, the step of sending, by the remote MCAL interface, a service call request for obtaining a service of the interface of the abstract layer of the microcontroller to the service interface, and the step of sending, by the service interface, a return value fed back by the service end to the logic module of the upper layer of the microcontroller includes:

step S201, the service interface adopts SOME/IP protocol to transmit interface parameters to the client SOME/IP conversion module;

Step S202, the client SOME/IP conversion module sequences the service ID and the service parameter list to form a first data stream, and transmits the first data stream to the client socket adaptation module;

step 203, the client socket adaptation module adds a header to the first data stream to form a first TCP/IP packet, and transmits the first TCP/IP packet to the TCP/IP module;

step S204, the client TCP/IP module sends a first TCP/IP message to the server TCP/IP module through an Ethernet interface;

step S205, the server TCP/IP module transmits the received first TCP/IP message to a server socket adapting module;

step S206, the server socket adapting module strips the header of the first TCP/IP message to obtain a first data stream, and transmits the first data stream to the server SOME/IP conversion module;

step S207, after the server SOME/IP conversion module deserializes the first data stream, a service ID and a service parameter list are obtained, and a corresponding microcontroller abstraction layer function is called to generate a return value;

step S208, the microcontroller abstract layer of the server transmits the return value to the SOME/IP conversion module of the server;

step S209, the server-side SOME/IP conversion module sequences the return value to obtain a second data stream, and transmits the second data stream to the server-side socket adaptation module;

Step S210, the server socket adapting module adds a header to the second data stream to form a second TCP/IP message, and the second TCP/IP message is transmitted to the server TCP/IP module;

step S211, the server TCP/IP module sends a second TCP/IP message to the client TCP/IP module;

step S212, the client TCP/IP module transmits the received second TCP/IP message to the client socket adapting module;

step S213, the client socket adapting module strips the header of the second TCP/IP message to obtain a second data stream, and transmits the second data stream to the client SOME/IP converting module;

step S214, the client-side SOME/IP conversion module deserializes the second data stream, obtains a return value, and transmits the return value to the microcontroller abstract layer interface adaptation module of the client-side;

in step S215, the interface adaptation module of the abstract layer of the microcontroller of the client transmits the return value to the upper logic module of the microcontroller.

Among them, the Socket Adapter module is also called Socket Adapter module, or SoAd module, and the main purpose of the Socket Adapter module is to create an interface between an AUTOSAR communication service module using PDUs (such as PDU Router) and a Socket-based TCP/IP stack.

In the communication method of the cross-platform automobile open system architecture, the automobile open system architecture is set to be a client and a server, the client comprises a microcontroller abstract layer interface adapting module, the microcontroller abstract layer interface adapting module comprises a far-end MCAL interface, the server comprises a microcontroller and a microcontroller abstract layer, and when the microcontroller abstract layer interface adapting module receives a microcontroller abstract layer calling request from a microcontroller abstract layer logic module of a microcontroller upper layer, the microcontroller abstract layer of the server is called through the far-end MCAL interface to provide corresponding microcontroller abstract layer interface service; the remote MCAL interface is a bottom layer driver of the client, interface calling centralized in an application layer is avoided, feedback speed is improved, the remote MCAL interface can be accessed to a microcontroller abstract layer of the server without complex protocol conversion, and development difficulty is reduced.

For specific limitations regarding the communication method of the cross-platform vehicle open system architecture, reference may be made to the above limitation of the cross-platform vehicle open system architecture, and no further description is given here.

It should be understood that, although the steps in the flowcharts of fig. 5-8 are shown in order as indicated by the arrows, these steps are not necessarily performed in order as indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps of fig. 5-8 may include multiple sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, nor does the order in which the sub-steps or stages are performed necessarily occur in sequence, but may be performed alternately or alternately with at least a portion of other steps or sub-steps or stages of other steps.

It can be understood that the application realizes the interface coordination of the client and a plurality of service ends by setting the automobile open system architecture as the client and the service ends, and is particularly shown in fig. 9.

As shown in fig. 9, the present application publishes the MCAL interface that can only be used locally in the open system architecture of the automobile to the network for other service terminals to form a remote MCAL interface. After the scheme is adopted, the server with insufficient peripheral resources can be used as a client to call MCAL resources of other controllers besides using local MCAL resources by means of the AUTOSAR architecture. And for the service end with spare peripheral resources, the remote service end can be used as a service provider to provide idle MCAL resources, so that the resource maximum utilization of the whole vehicle system is achieved.

As shown in fig. 10, for the MCAL interface call request issuing end, where the client may be used as multiple service ends, the same controller may also provide different services to multiple remote Electronic Control Units (ECU), so as to achieve maximum utilization of hardware resources. In fig. 10, the client is taken as the called remote end, which has a remote electric control unit to provide support for the client, and the multiple service ends receive MCAL interface call requests of the corresponding electric control units to the client to realize access call to the client. Specifically, the complex driver layer is in various forms, and includes I/O driver, I/O hardware abstraction, microcontroller driver, memory driver, and communication driver. The electronic control unit abstract layer adopts on-chip device abstraction, storage hardware abstraction or communication hardware abstraction realization. The remote MCAL interface is implemented with a specific driving unit of a complex driving layer or with a MCAL-like interface. At this time, the remote MCAL interface receives information of a plurality of servers as a client side.

In fig. 10, three servers are listed and are communicatively connected to the same client through a remote MCAL interface. The first electronic control unit is connected with the first service end through the MCAL-like interface, and the remote electronic control unit of the client is called by connecting the first service end with the client; the second electronic control unit is connected with a second service end through a storage drive, a communication drive and an I/O drive, and the remote electronic control unit of the calling client is connected with the client by the second service end;

the third electronic control unit is connected with a third service end through a storage drive, a communication drive and an I/O drive, and the remote electronic control unit of the calling client is connected with the client by the third service end; and when the third service end has abundant hardware resources, the third service end can be connected with the service ends of other automobile open system architectures, and the abundant hardware resources of the third service end can provide support for the service ends of other automobile open system architectures.

Because the MCAL interface related by the invention is standardized, the name, the parameter and the return value of the MCAL interface are definitely defined in the AUTOSAR standard, no additional service design is needed in the development process, frequent change of a service matrix in the development process is avoided, and the design time and the communication cost are reduced.

Meanwhile, the invention expands the communication protocol of the service bottom layer, and besides using the service interface based on SOME/IP, part of the low-end controllers without Ethernet modules can also transmit through CANTP communication, so that the middle-end and low-end ECU can also smoothly transition into an SOA service architecture system without using complex network signal to service conversion.

In the development and debugging stage, the original software generated based on the cross compiling mode can only run on the ECU, and the simulation debugging tool provided by a provider can only be used for setting up a complicated debugging environment and has a limited debugging method. If the scheme is adopted, part of AUTOSAR upper layer software CAN be switched to PC environment operation only through Ethernet or CAN equipment connection, input and output of an actual ECU are directly controlled, and more comprehensive and detailed test is carried out through a mature software testing tool at the PC end.

In one embodiment, a vehicle-mounted computer is provided, which may be a terminal, and an internal structure thereof may be as shown in fig. 11. The vehicle-mounted computer comprises a processor, a memory, a network interface, a display screen and an input device which are connected through a system bus. Wherein the processor of the vehicle-mounted computer is used for providing computing and control capabilities. The memory of the vehicle-mounted computer comprises a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the vehicle-mounted computer is used for communicating with an external terminal through network connection. The computer program, when executed by a processor, implements a method of communication across a platform-free automotive open system architecture. The display screen of the vehicle-mounted computer can be a liquid crystal display screen or an electronic ink display screen, the input device of the vehicle-mounted computer can be a touch layer covered on the display screen, can also be a key, a track ball or a touch pad arranged on the shell of the vehicle-mounted computer, and can also be an external keyboard, a touch pad or a mouse and the like.

It will be appreciated by those skilled in the art that the architecture shown in fig. 11 is merely a block diagram of some of the architecture relevant to the present application and is not intended to limit the vehicle computer to which the present application may be applied, and that a particular vehicle computer may include more or fewer components than those shown, or may incorporate some of the components, or have a different arrangement of components.

In one embodiment, a vehicle-mounted computer is provided, comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, the processor implementing the following steps when executing the computer program:

controlling the interface adaptation module of the client-side microcontroller abstract layer to detect a microcontroller abstract layer call request from the upper logic module of the microcontroller in real time;

when the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters;

if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module;

If not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

Specific limitations regarding implementation steps of the processor when executing the computer program may be found in the above limitations for a method of cross-platform automotive open system architecture, and will not be described in detail herein.

In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor, performs the steps of:

controlling the interface adaptation module of the client-side microcontroller abstract layer to detect a microcontroller abstract layer call request from the upper logic module of the microcontroller in real time;

when the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters;

if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module;

if not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

For specific limitations regarding implementation steps of the computer program when executed by the processor, reference may be made to the above limitation of the method of cross-platform automotive open system architecture, which is not described in detail herein.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored on a non-transitory computer readable storage medium, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), memory bus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples illustrate only a few embodiments of the application, which are described in detail and are not to be construed as limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.

Claims (10)

1. The cross-platform automobile open system architecture is characterized by comprising a client and a server;

the client comprises a microcontroller abstract layer interface adaptation module and a microcontroller upper layer logic module, wherein the microcontroller abstract layer interface adaptation module comprises a local MCAL interface and a remote MCAL interface;

the server comprises a microcontroller and a microcontroller abstract layer, and the microcontroller abstract layer is in communication connection with the remote MCAL interface;

When the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters; if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module; if not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

2. The cross-platform automotive open system architecture of claim 1, wherein the microcontroller abstraction layer and the remote MCAL interface implement a servitized communication connection through a service interface; the service interface realizes communication between the electronic devices in a communication protocol mode.

3. The cross-platform automotive open system architecture of claim 2, wherein when the service interface employs a CAN-transport-layer-based SOME/IP-like protocol, the service interface comprises a client service data parsing module, a client CAN transport layer, a server service data parsing module, and a server CAN transport layer.

4. The cross-platform automotive open system architecture of claim 2, wherein when the service interface employs a SOME/IP protocol, the service interface comprises a client SOME/IP conversion module, a client socket adaptation module, a client TCP/IP module, a server SOME/IP conversion module, a server socket adaptation module, and a server TCP/IP module.

5. The cross-platform automotive open system architecture of claim 1, wherein the microcontroller upper layer logic module comprises an application layer, a runtime environment layer, a service layer, an electronic control unit abstraction layer, a complex driver layer.

6. A method of communicating across a platform automotive open system architecture as claimed in any one of claims 1 to 5, comprising the steps of:

controlling the interface adaptation module of the client-side microcontroller abstract layer to detect a microcontroller abstract layer call request from the upper logic module of the microcontroller in real time;

when the interface adaptation module of the abstract layer of the microcontroller receives a call request of the abstract layer of the microcontroller from the logic module of the upper layer of the microcontroller, whether the call request is a remote call or not is identified through interface parameters;

if yes, transmitting a microcontroller abstract layer calling request to a microcontroller abstract layer of the server through the remote MCAL interface, and transmitting an execution result fed back by the server to a microcontroller upper logic module;

If not, executing the local micro-controller abstract layer call by the micro-controller abstract layer call request through the local MCAL interface.

7. The method according to claim 5, wherein the steps of transferring the call request of the micro-controller abstraction layer to the micro-controller abstraction layer of the server through the remote MCAL interface and transferring the execution result fed back by the server to the upper logic module of the micro-controller include:

when the microcontroller upper logic module of the client side invokes the microcontroller abstract layer interface service of the server side, if the microcontroller abstract layer interface adaptation module identifies that the invocation belongs to remote invocation, the interface parameter is transmitted to a remote MCAL interface;

the remote MCAL interface sends a service call request for acquiring the interface of the abstract layer of the microcontroller to the service interface, and the service interface transmits the service call request for acquiring the interface of the abstract layer of the microcontroller to the service end and transmits a return value fed back by the service end to the upper logic module of the microcontroller.

8. The method according to claim 7, wherein the remote MCAL interface sends a service call request for acquiring the interface of the micro-controller abstraction layer to the service interface, the service interface transmits the service call request for acquiring the interface of the micro-controller abstraction layer to the service end, and transmits a return value fed back by the service end to the upper logic module of the micro-controller, the steps including:

The service interface adopts a class SOME/IP protocol based on a CAN transmission layer, and transmits interface parameters in an interface service call request of an obtained microcontroller abstract layer to a client service data analysis module;

the client data service analysis module combines the service ID and the service parameter list into service data and transmits the service data to the client CAN transmission layer;

the client CAN transmission layer sends service data to the server CAN transmission layer through a CAN interface;

after the service end CAN transmission layer receives the service data, the service data is transmitted to a service end service data analysis module;

the server-side data analysis module analyzes a service ID and a service parameter list from the service data and calls a corresponding microcontroller abstract layer function to generate a return value;

the microcontroller abstract layer of the server transmits the return value to the service data analysis module;

the service data analysis module packs the returned values and transmits the packed values to the CAN transmission layer of the service end;

the CAN transmission layer of the server sends the return value to the CAN transmission layer of the client;

the client CAN transmission layer transmits the received data to the client service data analysis module;

The client service data analysis module strips a return value from data and provides the return value to the microcontroller abstract layer interface adaptation module of the client;

the microcontroller abstraction layer interface adaptation module of the client communicates a return value to the microcontroller upper layer logic module.

9. The method according to claim 7, wherein the remote MCAL interface sends a service call request for acquiring the interface of the micro-controller abstraction layer to the service interface, the service interface transmits the service call request for acquiring the interface of the micro-controller abstraction layer to the service end, and transmits a return value fed back by the service end to the upper logic module of the micro-controller, the steps including:

the service interface adopts SOME/IP protocol to transmit interface parameters to the client SOME/IP conversion module;

the client SOME/IP conversion module sequences the service ID and the service parameter list to form a first data stream, and transmits the first data stream to the client socket adaptation module;

the client socket adapting module adds a header to the first data stream to form a first TCP/IP message which is transmitted to the transmission control protocol/Internet protocol module;

The client TCP/IP module sends a first TCP/IP message to the server TCP/IP module through an Ethernet interface;

the server TCP/IP module transmits the received first TCP/IP message to the server socket adapting module;

the server socket adapting module strips the header of the first TCP/IP message to obtain a first data stream and transmits the first data stream to the server SOME/IP conversion module;

the server SOME/IP conversion module deserializes the first data stream to obtain a service ID and a service parameter list, and calls a corresponding microcontroller abstraction layer function to generate a return value;

the microcontroller abstract layer of the server transmits the return value to the SOME/IP conversion module of the server;

the server-side SOME/IP conversion module sequences the return value to obtain a second data stream, and transmits the second data stream to the server-side socket adaptation module;

the server socket adapting module adds a header to the second data stream to form a second TCP/IP message which is transmitted to the server TCP/IP module;

the server-side TCP/IP module sends a second TCP/IP message to the client-side TCP/IP module;

the client TCP/IP module transmits the received second TCP/IP message to the client socket adapting module;

The client socket adapting module strips the header of a second TCP/IP message to obtain a second data stream and transmits the second data stream to the client SOME/IP conversion module;

the client SOME/IP conversion module deserializes the second data stream to obtain a return value and transmits the return value to the microcontroller abstract layer interface adaptation module of the client;

the microcontroller abstraction layer interface adaptation module of the client communicates a return value to the microcontroller upper layer logic module.

10. A vehicle-mounted computer comprising a memory, a processor and a computer program stored on the memory and executable on the processor, characterized in that the processor implements the steps of the method according to any one of claims 6 to 9 when the computer program is executed by the processor.