Automotive open system architecture, data processing method, medium and vehicle-mounted device

Abstract

The embodiment of the application discloses a kind of automobile open system architecture, data processing method, medium and vehicle-mounted equipment, the automobile open system architecture includes classic platform CP automobile open system architecture, wherein:CP automobile open system architecture includes data distribution service DDS protocol stack component, DDS protocol stack component is integrated in CP automobile open system architecture in complex drive form;DDS protocol stack component includes: data center release subscription DCPS layer and data local reconstruction DLR layer, DCPS layer is used to the data object of application program release or subscription target service, DLR layer is used to the data object of application program release or subscription target service reconstruction.According to the technical scheme of the embodiment of the application, DDS protocol stack can be integrated in classic platform AUTOSAR.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of vehicle communication, in particular to an automobile open system architecture, a data processing method, a storage medium and a vehicle-mounted device. BACKGROUND

[0002] With the development of vehicle intelligent interconnection technology, the functions of vehicle-mounted electronic devices are becoming more and more rich, and the DDS (Data Distribution Service) protocol applied in the military and aviation fields gradually obtains attention and recognition in the automobile industry due to its unique functional characteristics and performance. Integrating DDS communication middleware in automobile electronic ECU (Electronic Control Unit) products has become a realistic demand.

[0003] With the wide application of CP (Classic Platform) AUTOSAR (AUTomotive Open System ARchitecture) standard in the automobile industry, many host manufacturers begin to apply CP AUTOSAR methodology to construct ECU product software architecture in the development of electronic and electrical systems. The CP AUTOSAR standard and architecture already contain SOME / IP (Scalable service-Oriented MiddlewarE over IP) protocol stack for the automobile field, but the DDS protocol stack in CP AUTOSAR has not been standardized.

[0004] Therefore, how to integrate the DDS protocol in the classic platform AUTOSAR has become a technical problem to be solved. SUMMARY

[0005] The embodiments of the present application provide an automobile open system architecture, a data processing method, a storage medium and a vehicle-mounted device, which can integrate the DDS protocol in the classic platform AUTOSAR. The technical solution is as follows:

[0006] In a first aspect, the embodiments of the present application provide an automobile open system architecture, which comprises a classic platform CP automobile open system architecture, and wherein:

[0007] The CP automobile open system architecture comprises a data distribution service DDS protocol stack component, and the DDS protocol stack component is integrated in the CP automobile open system architecture in the form of a complex driver.

[0008] The DDS protocol stack component comprises a data centering publishing and subscribing DCPS layer and a data local reconstruction DLR layer, the DCPS layer is used for an application program to publish or subscribe to a data object of a target service, and the DLR layer is used for reconstructing the data object of the target service published or subscribed to by the application program.

[0009] In some example embodiments, based on the above scheme, the DDS protocol stack component comprises a DDS client, and the automotive open system architecture further comprises an adaptive AP automotive open system architecture, and the AP automotive open system architecture comprises a DDS agent,

[0010] The DDS agent is configured to communicate with the DDS client through a service interface, receive service data of the DDS client, and process the service data.

[0011] In some example embodiments, based on the above scheme, the automotive open system architecture further comprises a static configuration module and a dynamic configuration module, wherein,

[0012] The static configuration module is configured to configure configuration items of static resources corresponding to the DDS client and the DDS agent;

[0013] The dynamic configuration module is configured to configure configuration items of dynamic resources corresponding to the DDS client and the DDS agent.

[0014] In some example embodiments, based on the above scheme, the CP automotive open system architecture and the AP automotive open system architecture each comprise an application layer, a running environment layer and a basic software layer, and the application layer and the basic software layer communicate through the running environment layer.

[0015] In some example embodiments, based on the above scheme, the automotive open system architecture further comprises a publisher module and a subscriber module, the subscriber module is arranged at the application layer of the CP automotive open system architecture, and the publisher module is arranged at the application layer of the AP automotive open system architecture, wherein:

[0016] The publisher module is configured to provide a data object to the CP automotive open system architecture;

[0017] The subscriber module is configured to obtain a required data object from the AP automotive open system architecture.

[0018] In some example embodiments, based on the above scheme, the DCPS layer further comprises a global data space, wherein:

[0019] The publisher module is configured to provide a data object to the CP automotive open system architecture through the global data space;

[0020] The subscriber module is configured to acquire required data objects from the AP car open system architecture through the global data space.

[0021] In some example embodiments, based on the above scheme, the DLR layer comprises a packaging module and an index module, wherein:

[0022] The packaging module is configured to package services provided by the DCPS layer in the form of service classes, and the service classes are generated in the form of local language structures.

[0023] The index module is configured to establish a corresponding relationship between the service classes and the services corresponding to the DCPS layer.

[0024] In a second aspect, the embodiments of the present application provide a data processing method, applied to a car open system architecture, wherein the car open system architecture comprises a classic platform (CP) car open system architecture, the CP car open system architecture comprises a data distribution service (DDS) protocol stack component, the DDS protocol stack component is integrated in the CP car open system architecture in the form of a complex driver, the DDS protocol stack component comprises a DCPS layer and a DLR layer, and the method comprises the following steps:

[0025] receiving, by the DCPS layer, data objects of target services published or subscribed by an application program;

[0026] reconstructing, by the DLR layer, the data objects of the target services published or subscribed by the application program, so that.

[0027] In a third aspect, the embodiments of the present application provide a computer storage medium, which stores a plurality of instructions, and the instructions are suitable for being loaded by a processor and performing the steps of the above method.

[0028] In a fourth aspect, the embodiments of the present application provide a vehicle-mounted device, comprising a processor and a memory, wherein the memory stores a computer program, and the computer program is suitable for being loaded by the processor and performing the steps of the above method.

[0029] The technical solutions provided by some embodiments of the present application have at least the following beneficial effects:

[0030] On one hand, encapsulating and customizing the DDS protocol stack components in the form of complex drivers and integrating them into the CP AUTOSAR can integrate the DDS protocol stack in the classic platform AUTOSAR; on the other hand, the DLR layer of the DDS protocol stack components is established on the basis of the lower-layer DCPS layer, and by integrating the services provided by the DCPS layer to the application layer, the application program can directly interact with the underlying services, so that the user can directly access the changed data of the underlying services, and achieve seamless connection with the underlying services of the native language structure. BRIEF DESCRIPTION OF DRAWINGS

[0031] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the embodiments or the prior art description. Obviously, the drawings in the following description only some embodiments of the present application, and for those skilled in the art, other drawings can also be obtained without creative labor on the basis of these drawings.

[0032] Figure 1 A schematic diagram of a system architecture of an automotive open system architecture is shown;

[0033] Figure 2 A schematic diagram of an automotive open system architecture is shown according to some embodiments of the present application;

[0034] Figure 3 A schematic diagram of an automotive open system architecture is shown according to some embodiments of the present application;

[0035] Figure 4 A schematic diagram of an automotive open system architecture is shown according to some embodiments of the present application;

[0036] Figure 5 A schematic diagram of a data processing method is shown according to some embodiments of the present application;

[0037] Figure 6 A schematic diagram of a vehicle-mounted device is shown according to some embodiments of the present application. DETAILED DESCRIPTION

[0038] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0039] First, the terms involved in the embodiments of the present application are explained and described.

[0040] DDS: A middleware protocol and application program interface (API) standard that provides a low-latency, highly reliable, scalable communication architecture standard for distributed systems. DDS data sharing is based on topics, and applications can determine the data types they contain without relying on other context information. At the same time, DDS can automatically store, publish or subscribe to data in a user-defined manner, allowing applications to write or read data as if it were local data.

[0041] CAN bus: A data bus in the traditional vehicle architecture that can carry a large amount of data and is an ISO international standard serial communication protocol.

[0042] LIN (Local Interconnect Network) bus: A data bus in the traditional vehicle architecture, used to implement distributed electronic system control in vehicles, can carry a small amount of data, mainly used to control some simple in-vehicle devices, and is an auxiliary bus network.

[0043] SOME / IP protocol: An automotive middleware solution for control messages that enables service-oriented communication between controllers. SOME / IP provides a wide range of middleware functions such as serialization, remote procedure call, service discovery and subscription to enable ECU software to communicate with each other.

[0044] ARXML (AUTOSAR eXtensible Markup Language): This standard describes how to serialize the AUTOSAR model into an AUTOSAR XML description, providing support for interoperability between AUTOSAR tools.

[0045] AUTOSAR: A consortium dedicated to developing automotive electronic software standards, committed to developing an open, standardized software architecture for the automotive industry.

[0046] In the following, the technical solutions of the automobile open system architecture of the embodiments of the present application will be described in detail with reference to the accompanying drawings.

[0047] Figure 1 A schematic diagram of the system architecture of the automobile open system architecture provided by the embodiments of the present application is shown.

[0048] Referring to Figure 1As shown, the system architecture of the AUTOSAR 110 includes an application layer 110, a runtime environment layer 120, and a basic software layer 130. The application layer 110 communicates with the basic software layer 130 through the runtime environment layer 120.

[0049] In an example embodiment, the application layer 110 includes at least one application program, such as an AUTOSAR software component, an AUTOSAR sensor or actuator component, etc. The runtime environment layer 120 is a layer that provides communication services for the application program. The AUTOSAR software component of the application layer 110 can communicate with other components, such as an ECU or a service, through the runtime environment layer 120.

[0050] The basic software layer 130 mainly includes four parts: a microcontroller abstraction layer, an ECU abstraction layer, a service layer, and a complex driver. The microcontroller abstraction layer contains hardware-related drivers that can be used to access memory, communication, and I / O, etc.; the ECU abstraction layer is responsible for providing a unified access interface to access communication, memory, or I / O, so that it is not necessary to consider whether these resources are provided by a microprocessor or an external device; the service layer provides various types of background services, such as network services, memory management, and bus communication services, etc., and the operating system is located in the service layer.

[0051] The complex driver spans from the hardware to the runtime environment layer 120, and its main task is to integrate non-standard functional modules with special purposes, embed this part of the function into the AUTOSAR basic software layer, and thus realize the processing of complex sensors and the specific functions and time requirements of the actuator. The complex driver is closely related to the single-chip microcomputer and the ECU hardware. Its upper program interface is specified and implemented according to AUTOSAR; its lower program interface is limited by the standard interface program. The complex driver can realize the evaluation of complex sensors and the control of actuators, such as fuel injection control, electromagnetic valve control, incremental position detection, etc.

[0052] Figure 2 A schematic diagram of an automotive open system architecture is shown, which is provided according to some embodiments of the present application. In the following, the automotive open system architecture in the example embodiment is described in detail with reference to the accompanying drawings.

[0053] Reference Figure 2 As shown, the automotive open system architecture 100 includes a CP (Classic AUTOSAR, classic platform) automotive open system architecture 100, wherein: the CP AUTOSAR includes a DDS protocol stack component 132, and the DDS protocol stack component 132 is integrated in the CP automotive open system architecture 100 in the form of a complex driver.

[0054] CP AUTOSAR directly interacts with sensors and actuators by extracting peripherals of microcontrollers as signals, which can be used by applications to process sensor / actuator input / output values and send and receive bus data. CP AUTOSAR connects vehicle network communication interfaces such as LIN bus, CAN bus and Ethernet. CP AUTOSAR also supports sending and receiving service-oriented resources such as events, fields and methods, and a protocol converter in the runtime environment converts the service-oriented protocol interface into a standardized interface.

[0055] Complex Driver (CDD) provides AUTOSAR interface to upper layer through running environment layer 120 upwardly, and can directly access MCU (Microcontroller Unit) registers downwardly. In an example embodiment, software components of CP AUTOSAR application level encapsulate and customize integration of DDS protocol stack components 132 in the form of complex driver through communication services of CP AUTOSAR, for example, encapsulate interfaces of DDS protocol stack components 132, and use DDS to communicate between ECUs through standard API by taking DDS protocol stack components 132 as static link library. DDS is data-centric, and is used to accommodate dynamic data from different sources. By using DDS protocol stack components 132, applications can directly interact with data in a shared global data space.

[0056] Further, in an example embodiment, DDS protocol stack components 132 include a DCPS (Data-Centric Publish-Subscribe) layer 1322 and a DLR (Data Local Reconstruction) layer 1324. The DCPS layer 1322 is used for applications to publish or subscribe to data objects of target services, and the DLR layer 1324 is used for reconstructing data objects of target services published or subscribed to by applications.

[0057] Further, in an example embodiment, the DLR layer 1324 includes an encapsulation module and an index module. The encapsulation module is used for encapsulating services provided by the DCPS layer 1322 in the form of service classes, and the service classes are generated in the form of local language structures. The index module is used for establishing a corresponding relationship or mapping relationship between service classes and corresponding services of the DCPS layer.

[0058] The DCPS layer 1322 is the core and basis of the DDS protocol stack component 132, and provides basic services of communication. The encapsulation module in the DLR layer 1324 encapsulates the services provided by the DCPS layer 1322 in the form of service classes, and generates the services provided by the DCPS layer 1322 in the form of a local language structure, abstracts the services provided by the DCPS layer 1322, and the index module in the DLR layer 1324 establishes a mapping relationship between the service classes and the underlying services in the DLR layer 1324. The DLR layer 1324 is established on the basis of the underlying DCPS layer 1322, and the services provided by the DCPS layer 1322 are integrated into the application layer, so that the application program can directly interact with the underlying services, and the user can directly access the data changed by the underlying services, and achieve seamless connection with the local language structure.

[0059] According to Figure 2 In the technical solution in the example embodiment, on the one hand, the DDS protocol stack component is encapsulated and customized and integrated into the CP AUTOSAR in the form of a complex driver, so that the DDS protocol stack can be integrated into the classic platform AUTOSAR; on the other hand, the DLR layer of the DDS protocol stack component is established on the basis of the underlying DCPS layer, the services provided by the DCPS layer are integrated into the application layer, so that the application program can directly interact with the underlying services, the user can directly access the data changed by the underlying services, and seamless connection with the underlying services of the local language structure is achieved.

[0060] In addition, in the example embodiment, the DCPS layer 1322 converts the user's demand for resources and the availability of resources into QoS (Quality of Service), and the QoS includes various policy forms, each policy form describes the behavior of the service by being associated with a value name. The DCPS layer 1322 provides the functions of publishing and subscribing data. The publishing and subscribing are associated through a topic, the information is published through the topic association, the publisher and subscriber entities are created, and the QoS parameters are set for these entities.

[0061] For example, the DDS programs the availability of resources, the occupation degree of the resources by the provider, and the expectation degree of the resources by the requester into topic QoS, publisher QoS and subscriber QoS respectively. The QoS parameters virtualize the underlying and the entire communication mechanism, including bandwidth limitation, reliability, latency and resource limitation. Whether the publisher QoS and the subscriber QoS are compatible is checked through the DDS middleware, so that the connection is established or an exception is prompted. The communication process is controlled through the QoS, and the flexibility of communication can be significantly increased.

[0062] Figure 3 A schematic diagram of an automotive open system architecture is shown, according to further embodiments of the present application.

[0063] Referring toFigure 3 As shown, the automotive open system architecture further includes an AP (Adaptive Platform) AUTOSAR, the AP AUTOSAR including the DDS agent 320, the DDS protocol stack component of the CP AUTOSAR including the DDS client 310, the CP automotive open system architecture and the AP automotive open system architecture each including an application layer, a runtime environment layer, and a basic software layer, the application layer and the basic software layer being in communication via the runtime environment layer.

[0064] The DDS agent 320 is configured to communicate with the DDS client 310 via a service interface 330, receive service data from the DDS client 310, and process the service data. AUTOSAR service interfaces are typically defined using ARXML, a modeling language derived from the AUTOSAR UML meta-model. As a result of code generation, an ARXML compiler generates code for the agent and framework for both client and server applications. On the client side, the application instantiates the agent binding to the service instance running on the server side. AUTOSAR service provides the following function call interfaces: DDS protocol stack initialization, DDS protocol stack periodic scheduling, DDS protocol stack data sending request, DDS protocol stack data receiving notification, and DDS protocol stack de-initialization. Meanwhile, DDS complex driving provides the following resource parameters: Participates - different communication nodes within the DDS domain, Topic - specific kind of data, Publisher - data producer communication node, Subscriber - data consumer communication node. Different resources are identified by resource ids. The upper layer application instance uses the corresponding resource parameters to call the protocol stack interface according to the actual functional requirements, to realize data interaction within the DDS domain.

[0065] According to Figure 3 In an example embodiment, on the one hand, due to the wide use of heterogeneous multi-core SOC hardware chips in the core ECU components of the vehicle electronic and electrical architecture, and the deployment of two sets of software architectures, CP AUTOSAR and AP AUTOSAR, and with the help of the client-server architecture of the DDS protocol stack, the DDS protocol stack is integrated in the CP AUTOSAR through the DDS complex driving, so that the DDS communication function can be integrated in the CP real-time core with relatively limited computing power and resources, and the standardized inter-core communication middleware supporting service-oriented functions can be realized on the heterogeneous multi-core SOC chip hardware platform. On the other hand, the CP AUTOSAR can improve the data processing capability with the help of the computing resources of the AP AUTOSAR.

[0066] In addition, in the example embodiment, the automotive open system architecture further comprises a static configuration module and a dynamic configuration module, wherein the static configuration module is configured to configure configuration items of static resources corresponding to the DDS client and the DDS agent; and the dynamic configuration module is configured to configure configuration items of dynamic resources corresponding to the DDS client and the DDS agent.

[0067] In the example embodiment, the DDS protocol stack component of the automotive open system architecture comprises a static configuration module and a dynamic configuration module. The static configuration module adopts a mature product verified by an open source platform. The dynamic configuration module customizes a development module definition file in ARXML format, defines configuration items of the DDS module, and configures configuration items of dynamic resources corresponding to the DDS client and the DDS agent. For example, the ARXML file is imported by using a development tool chain (for example, Vector Davinci) and each configuration item of the dynamic resource is set, and a code generation tool corresponding to the DDS protocol stack component is used to realize dynamic configuration code generation and integration of the development tool chain.

[0068] According to the technical solution in the above example embodiment, the configuration items of the static resources corresponding to the DDS client and the DDS agent are configured by the static configuration module, and the configuration items of the dynamic resources corresponding to the DDS client and the DDS agent are configured by the dynamic configuration module, so that seamless integration of the DDS protocol stack in the classic platform AUTOSAR platform can be realized, the integration scheme can be compatible with various versions of the CP AUTOSAR standard, and can be fully integrated with the CP AUTOSAR development tool chain and the development process.

[0069] Figure 4 A schematic diagram of an automotive open system architecture according to some other embodiments of the present application is shown.

[0070] Referring to Figure 4 As shown in the figure, the AUTOSAR further comprises a publisher module 410 and a subscriber module 420, the subscriber module 420 is arranged at an application layer of the CP AUTOSAR, and the publisher module 410 is arranged at an application layer of the AP AUTOSAR, wherein the publisher module 410 serves as a service provider to provide data objects to the CP automotive open system architecture, and the subscriber module 420 serves as a service consumer to obtain required data objects from the AP automotive open system architecture.

[0071] Further, in the example embodiment, the DCPS layer further comprises a global data space, a physical storage space of the global data space can be located in the shared storage space of the hardware layer 350, the publisher module 410 is configured to provide data objects to the AP automotive open system architecture through the global data space; the subscriber module 420 is configured to obtain required data objects from the AP automotive open system architecture through the global data space. The DDS provides a data distribution infrastructure, ensuring that information is correctly and efficiently transmitted to the appropriate recipient. The DCPS layer of the DDS establishes a concept of a global data space, and the publisher and the subscriber respectively publish and subscribe to the data types they need in the global space, and then perform data transmission after middleware processing, converting the traditional C / S mode to a data-centric service mode.

[0072] According to Figure 4 the technical solution in the example embodiment of the present application, the DCPS layer of the DDS establishes a concept of a global data space, and the publisher and the subscriber respectively publish and subscribe to the data types they need in the global space, and then perform data transmission after middleware processing, converting the traditional C / S mode to a data-centric service mode, weakening the relationship between the information publisher and the subscriber, removing the coupling between the components of the system, enhancing the flexibility of the system architecture, and facilitating the maintenance and scale expansion of the system.

[0073] The following is an embodiment of the method of the present application. For details not disclosed in the embodiment of the method of the present application, please refer to the embodiment of the automotive open system architecture of the present application.

[0074] Figure 5 A schematic diagram of a data processing method according to some embodiments of the present application is shown.

[0075] Referring to Figure 5 , the data processing method is applied to an automotive open system architecture, the automotive open system architecture comprises a classic platform CP automotive open system architecture, the CP automotive open system architecture comprises a data distribution service DDS protocol stack component, the DDS protocol stack component is integrated in the CP automotive open system architecture in a complex driving form, the DDS protocol stack component comprises a DCPS layer and a DLR layer, and the method comprises the following steps:

[0076] Step 510, receiving a data object of a target service published or subscribed by an application program through the DCPS layer;

[0077] Step 520, reconstructing the data object of the target service published or subscribed by the application program through the DLR layer.

[0078] In some example embodiments, based on the above scheme, the automotive open system architecture further comprises an adaptive AP automotive open system architecture, the AP automotive open system architecture comprises a DDS agent, and the method further comprises:

[0079] communicating with the DDS client through a service interface of the DDS agent, receiving service data of the DDS client, and processing the service data.

[0080] In some example embodiments, based on the above scheme, the automotive open system architecture further comprises a static configuration module and a dynamic configuration module, and the method further comprises:

[0081] configuring configuration items of static resources corresponding to the DDS client and the DDS agent through the static configuration module;

[0082] configuring configuration items of dynamic resources corresponding to the DDS client and the DDS agent through the dynamic configuration module.

[0083] In some example embodiments, based on the above scheme, the CP automotive open system architecture and the AP automotive open system architecture both comprise an application layer, a runtime environment layer, and a basic software layer, and the application layer and the basic software layer communicate through the runtime environment layer.

[0084] In some example embodiments, based on the above scheme, the automotive open system architecture further comprises a publisher module and a subscriber module, the subscriber module is arranged at the application layer of the CP automotive open system architecture, and the publisher module is arranged at the application layer of the AP automotive open system architecture, and the method further comprises:

[0085] providing data objects to the CP automotive open system architecture through the publisher module;

[0086] obtaining required data objects from the AP automotive open system architecture through the subscriber module.

[0087] In some example embodiments, based on the above scheme, the DCPS layer further comprises a global data space, and the method further comprises:

[0088] the publisher module provides data objects to the CP automotive open system architecture through the global data space;

[0089] the subscriber module obtains required data objects from the AP automotive open system architecture through the global data space.

[0090] In some example embodiments, based on the above scheme, the method further comprises:

[0091] The services provided by the DCPS layer are encapsulated in the form of service classes, and the service classes are generated in the form of native language structures; and a corresponding relationship between the service classes and the services corresponding to the DCPS layer is established.

[0092] According to the technical solutions in the example embodiments, Figure 5 In one aspect, the DDS protocol stack components are encapsulated and customized integrated into the CP AUTOSAR in the form of complex driving, so that the DDS protocol stack can be integrated into the classic AUTOSAR; and in another aspect, the DLR layer of the DDS protocol stack components is established on the basis of the lower-layer DCPS layer, so that the services provided by the DCPS layer are integrated into the application layer, and the user can directly access the changed data, achieving seamless connection with the native language structure.

[0093] It should be noted that the automobile open system architecture provided in the above embodiments is executed, and only the division of the above functional modules is used as an example for illustration. In actual application, the above functions can be completed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above.

[0094] In addition, the automobile open system architecture and the data processing method provided in the above embodiments belong to the same concept, and the implementation process is embodied in the embodiment of the automobile open system architecture, which will not be described here.

[0095] The embodiment of the present application further provides a computer storage medium, which can store a plurality of instructions, the instructions being suitable for being loaded and executed by a processor to perform the data processing method of the above embodiment. The specific execution process can be referred to the specific description of the above embodiment, which will not be described here.

[0096] The embodiment of the present application further provides a computer program product, which stores at least one instruction, the at least one instruction being loaded and executed by the processor to perform the data processing method of the above embodiment. The specific execution process can be referred to the specific description of the above embodiment, which will not be described here.

[0097] The embodiment of the present application further provides a chip, which is configured to perform the data processing method of the above embodiment. The specific execution process can be referred to the specific description of the above embodiment, which will not be described here.

[0098] In addition, please refer to Figure 6 The embodiment of the present application provides a structural schematic diagram of a vehicle-mounted device. As shown in Figure 6As shown, the vehicle-mounted device 600 can include at least one processor 601, at least one communication module 604, an input / output interface 603, a memory 605, and at least one communication bus 602.

[0099] The communication bus 602 is configured to realize the connection and communication between the components.

[0100] The input / output interface 603 can include a display screen (Display) and a camera (Camera). Optionally, the input / output interface 603 can further include a standard wired interface and a wireless interface.

[0101] The communication module 604 can optionally include a standard wired interface and a wireless interface (such as a WIFI interface). The communication module 604 includes a first gateway (for example, an S2S gateway) and a second gateway (for example, a C2C gateway). The first gateway uses a first communication protocol for communication, and the second gateway uses a second communication protocol for communication.

[0102] The processor 601 can include one or more processing cores. The processor 601 is connected to various parts of the vehicle-mounted device 600 through various interfaces and lines, and performs various functions of the server 600 and processes data by running or executing instructions, programs, code sets or instruction sets stored in the memory 605, and calling data stored in the memory 605. Optionally, the processor 601 can be implemented in at least one of a digital signal processing (DSP), a field-programmable gate array (FPGA), and a programmable logic array (PLA). The processor 601 can be integrated with a combination of one or more of a central processing unit (CPU), a graphics processing unit (GPU), and a modem. Among them, the CPU is mainly used to process the operating system, user interface, and application program; the GPU is used to render and draw the content to be displayed on the display screen; and the modem is used to process wireless communication. It can be understood that the above-mentioned modem can also not be integrated into the processor 601, but can be realized by a separate chip.

[0103] The memory 605 can include a random access memory (RAM) and can also include a read-only memory (ROM). Optionally, the memory 605 includes a non-transitory computer-readable storage medium. The memory 605 can be used to store instructions, programs, codes, code sets, or instruction sets. The memory 605 can include a program storage area and a data storage area, where the program storage area can store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the above-mentioned various method embodiments, etc.; the data storage area can store data involved in the above-mentioned various method embodiments, etc. The memory 605 can also be at least one storage device located away from the processor 601. As shown in Figure 6 The memory 605 as a computer storage medium can include an operating system, a communication module, an input / output interface module, and a data processing application program.

[0104] In the vehicle-mounted device 600 shown in Figure 6 The input / output interface 603 is mainly used to provide an interface for user input and obtain user input data; the processor 601 can be used to call the data processing application program stored in the memory 605, so that the processor 601 performs the steps in the data processing method according to various exemplary embodiments of the present disclosure. The vehicle-mounted device 600 includes an automotive open system architecture, which includes a classic platform (CP) automotive open system architecture, the CP automotive open system architecture includes a data distribution service (DDS) protocol stack component, the DDS protocol stack component is integrated in the CP automotive open system architecture in a complex driving form, and the DDS protocol stack component includes a DCPS layer and a DLR layer. For example, the processor 601 can perform the steps shown in Figure 5 Step 510: receiving, by the DCPS layer, a data object of a target service published or subscribed by an application; and step 520: reconstructing, by the DLR layer, the data object of the target service published or subscribed by the application.

[0105] The above is a schematic scheme of a vehicle-mounted device according to an embodiment of the present disclosure. The vehicle-mounted device can be a central gateway or other appropriate device such as a vehicle-mounted gateway, etc. It should be noted that the technical scheme of the vehicle-mounted device belongs to the same concept as the technical scheme of the above-mentioned automotive open system architecture, and the details of the technical scheme of the vehicle-mounted device that are not described in detail can be referred to the description of the technical scheme of the above-mentioned automotive open system architecture processing method.

[0106] In the description of the present application, it needs to be understood that the terms "first", "second" and the like are used only for descriptive purposes and are not to be construed as indicating or implying relative importance. In the description of the present application, it needs to be explained that, unless otherwise explicitly specified and limited, "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product or device including a series of steps or units is not limited to the listed steps or units, but optionally also includes steps or units not listed, or optionally also includes other steps or units inherent to the process, method, product or device. For those skilled in the art, the specific meaning of the above terms in the present application can be understood in specific cases. In addition, in the description of the present application, "multiple" means two or more, unless otherwise specified. The association relationship between the associated objects is described as "and / or", which means that there can be three relationships, for example, A and / or B can represent three cases: A exists alone, A and B exist together, and B exists alone. The character " / " generally represents a "or" relationship between the associated objects before and after it.

[0107] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing related hardware through a computer program. The program can be stored in a computer readable storage medium, and when the program is executed, it can include the processes of the above-mentioned embodiment methods. The storage medium can be a magnetic disc, an optical disc, a read-only memory or a random access memory, etc.

[0108] The above only discloses the preferred embodiments of the present application, and of course cannot limit the scope of the rights of the present application, so the equivalent changes made according to the claims of the present application still fall within the scope of the present application.

Claims

1. An automotive open system architecture, characterized by, The automobile open system architecture comprises a classic platform (CP) automobile open system architecture, wherein: The CP automobile open system architecture comprises a data distribution service (DDS) protocol stack component, which is integrated in the CP automobile open system architecture in a complex driving form; The DDS protocol stack component comprises a data-centric publish / subscribe layer and a data local reconstruction layer, the publish / subscribe layer is used for an application program to publish or subscribe to a data object of a target service, and the data local reconstruction layer is used for reconstructing the data object of the target service published or subscribed to by the application program; The DDS protocol stack component comprises a DDS client, and the automobile open system architecture further comprises an adaptive (AP) automobile open system architecture, the AP automobile open system architecture comprises a DDS proxy, The automobile open system architecture further comprises a static configuration module and a dynamic configuration module, wherein: The static configuration module is used for configuring configuration items of static resources corresponding to the DDS client and the DDS proxy; The dynamic configuration module is used for configuring configuration items of dynamic resources corresponding to the DDS client and the DDS proxy.

2. The automotive open system architecture according to claim 1, characterized in that The DDS proxy is used for communicating with the DDS client through a service interface, receiving service data of the DDS client, and processing the service data.

3. The automotive open system architecture of claim 1, wherein, The CP automobile open system architecture and the AP automobile open system architecture both comprise an application layer, a running environment layer and a basic software layer, and the application layer and the basic software layer communicate through the running environment layer.

4. The automotive open system architecture according to claim 3, wherein, The automobile open system architecture further comprises a publisher module and a subscriber module, the subscriber module is arranged at the application layer of the CP automobile open system architecture, and the publisher module is arranged at the application layer of the AP automobile open system architecture, wherein: The publisher module is used for providing a data object to the CP automobile open system architecture; The subscriber module is used for obtaining a required data object from the AP automobile open system architecture.

5. The automotive open system architecture according to claim 1, wherein, The publish / subscribe layer further comprises a global data space, a publisher module and a subscriber module, wherein: The publisher module is used for providing a data object to the CP automobile open system architecture through the global data space; The subscriber module is used for obtaining a required data object from the AP automobile open system architecture through the global data space.

6. The automotive open system architecture according to any one of claims 1 to 5, characterized in that, The data local reconstruction layer comprises an encapsulation module and an index module, wherein: The encapsulation module is used for encapsulating a service provided by the publish / subscribe layer in a service class, and the service class is generated in a local language structure; The index module is used for establishing a corresponding relationship between the service class and a service corresponding to the publish / subscribe layer.

7. A data processing method, characterized by, The method is applied to the automobile open system architecture of any one of claims 1-6, and the method comprises: Receiving, through the publish / subscribe layer, a data object of a target service published or subscribed to by an application program; Reconstructing, through the data local reconstruction layer, the data object of the target service published or subscribed to by the application program.

8. A computer storage medium storing a plurality of instructions adapted to be loaded and executed by a processor to perform the steps of the method of claim 7.

9. An in-vehicle device characterized by comprising: comprising: a processor and a memory storing a computer program adapted to be loaded and executed by the processor to perform the steps of the method of claim 7.

Images