CN115766915A - Automobile open system architecture, data processing method, medium and vehicle-mounted equipment - Google Patents
Automobile open system architecture, data processing method, medium and vehicle-mounted equipment Download PDFInfo
- Publication number
- CN115766915A CN115766915A CN202211352867.4A CN202211352867A CN115766915A CN 115766915 A CN115766915 A CN 115766915A CN 202211352867 A CN202211352867 A CN 202211352867A CN 115766915 A CN115766915 A CN 115766915A
- Authority
- CN
- China
- Prior art keywords
- system architecture
- open system
- layer
- data
- dds
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 16
- 239000013256 coordination polymer Substances 0.000 claims abstract 10
- 238000000034 method Methods 0.000 claims description 36
- 230000003068 static effect Effects 0.000 claims description 17
- 238000012545 processing Methods 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 5
- 238000005538 encapsulation Methods 0.000 claims description 5
- 238000004806 packaging method and process Methods 0.000 claims description 5
- 230000003044 adaptive effect Effects 0.000 claims description 4
- 101000871498 Homo sapiens m7GpppX diphosphatase Proteins 0.000 abstract 1
- MIQYPPGTNIFAPO-CABCVRRESA-N PS(6:0/6:0) Chemical compound CCCCCC(=O)OC[C@@H](OC(=O)CCCCC)COP(O)(=O)OC[C@H](N)C(O)=O MIQYPPGTNIFAPO-CABCVRRESA-N 0.000 abstract 1
- 102100033718 m7GpppX diphosphatase Human genes 0.000 abstract 1
- 230000006854 communication Effects 0.000 description 31
- 238000004891 communication Methods 0.000 description 30
- 239000000243 solution Substances 0.000 description 16
- 230000006870 function Effects 0.000 description 15
- 238000010586 diagram Methods 0.000 description 12
- 230000008569 process Effects 0.000 description 12
- 238000011161 development Methods 0.000 description 7
- 239000003795 chemical substances by application Substances 0.000 description 4
- 230000003993 interaction Effects 0.000 description 4
- 230000010354 integration Effects 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 2
- 238000013507 mapping Methods 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000011156 evaluation Methods 0.000 description 1
- 230000004927 fusion Effects 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 238000002347 injection Methods 0.000 description 1
- 239000007924 injection Substances 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 230000003313 weakening effect Effects 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
The embodiment of the application discloses an automobile open system architecture, a data processing method, a medium and a vehicle-mounted device, wherein 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, and the DDS protocol stack component is integrated in the CP automobile open system architecture in a complex driving form; the DDS protocol stack assembly comprises: the data-centric publishing and subscribing DCPS layer and the data local reconstruction DLR layer are used for an application program to publish or subscribe 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 by the application program. According to the technical scheme of the embodiment of the application, the DDS protocol stack can be integrated in the classical platform AUTOSAR.
Description
Technical Field
The present application relates to the field of vehicle-mounted communications technologies, and in particular, to an automobile open system architecture, a data processing method, a storage medium, and a vehicle-mounted device.
Background
With the development of vehicle intelligent interconnection technology, the functions of vehicle-mounted Electronic devices are more and more abundant, and a Data Distribution Service (DDS) protocol applied to military and aviation fields is gradually paid attention and approved in the automobile industry by virtue of unique functional characteristics and performance thereof, and it becomes a real requirement to integrate a DDS communication middleware in an automotive Electronic Control Unit (ECU) product.
With the wide application of the CP (Classic Platform) AUTOSAR (AUTomotive Open System ARchitecture) standard in the AUTomotive industry, many host factories begin to apply the CP AUTOSAR methodology to construct the ECU product software ARchitecture in the development of their electronic and electrical systems. The CP automotive standard and architecture already contain a service-Oriented Scalable MiddlewarE over IP (SOME/IP) protocol stack Oriented to the automotive field, but the DDS protocol stack in the CP automotive does not achieve standardization.
Therefore, how to integrate the DDS protocol in the classical platform AUTOSAR becomes a technical problem to be solved urgently.
Disclosure of Invention
The embodiment of the application provides an automobile open system architecture, a data processing method, a storage medium and vehicle-mounted equipment, and a DDS protocol can be integrated in a classical platform AUTOSAR. The technical scheme is as follows:
in a first aspect, an embodiment of the present application provides an automobile open system architecture, where the automobile open system architecture includes a classic platform CP automobile open system architecture, where:
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 a complex driving form;
the DDS protocol stack assembly comprises: the data-centric publish-subscribe DCPS layer is used for publishing or subscribing data objects of target services for application programs, and the DLR layer is used for reconstructing the data objects of the target services published or subscribed by the application programs.
In some exemplary embodiments, based on the above solution, the DDS protocol stack component includes a DDS client, the car open system architecture further includes an adaptive AP car open system architecture, the AP car open system architecture includes a DDS agent,
the DDS agent is used for communicating with the DDS client through a service interface, receiving service data of the DDS client and processing the service data.
In some exemplary embodiments, based on the above scheme, 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 the configuration items of the dynamic resources corresponding to the DDS client and the DDS proxy.
In some example embodiments, based on the above scheme, the CP automobile open system architecture and the AP automobile open system architecture each include an application layer, a runtime environment layer, and a base software layer, and the application layer and the base software layer communicate with each other through the runtime environment layer.
In some exemplary embodiments, based on the above solution, the automobile open system architecture further includes: a publisher module and a subscriber module, wherein the subscriber module is disposed in the application layer of the CP automobile open system architecture, and the publisher module is disposed in 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;
and the subscriber module is used for acquiring required data objects from the AP automobile open system architecture.
In some example embodiments, based on the above scheme, the DCPS layer further includes a global data space, wherein:
the publisher module is used for providing a data object to the CP automobile open system architecture through the global data space;
and the subscriber module is used for acquiring required data objects from the AP automobile open system architecture through the global data space.
In some example embodiments, based on the above scheme, the DLR layer includes an encapsulation module and an index module, wherein:
the packaging module is used for packaging the services provided by the DCPS layer in a service class form, and the service class is generated in a local language structure form;
the index module is used for establishing a corresponding relation between the service class and the service corresponding to the DCPS layer.
In a second aspect, an embodiment of the present application provides a data processing method, which is applied to an automobile open system architecture, where the automobile open system architecture includes a classic platform CP automobile open system architecture, the CP automobile open system architecture includes a data distribution service DDS protocol stack component, the DDS protocol stack component is integrated in the CP automobile open system architecture in a complex driving form, the DDS protocol stack component includes a DCPS layer and a DLR layer, and the method includes:
receiving a data object of a target service published or subscribed by an application program through the DCPS layer;
and reconstructing the data object of the target service published or subscribed by the application program through the DLR layer so as to enable the data object to be reconstructed.
In a third aspect, embodiments of the present application provide a computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the steps of the above-mentioned method.
In a fourth aspect, an embodiment of the present application provides an onboard apparatus, including: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the steps of the method as described above.
The beneficial effects brought by the technical scheme provided by some embodiments of the application at least comprise:
on one hand, the DDS protocol stack assembly is packaged and customized in a complex drive form and integrated into the CP AUTOSAR, and the DDS protocol stack can be integrated in the classical platform AUTOSAR; on the other hand, the DLR layer of the DDS protocol stack assembly is established on the basis of the DCPS layer at the lower layer, and by integrating the services provided by the DCPS layer into the application layer, the application program can directly perform data interaction with the bottom layer service, so that a user can directly access the data changed by the bottom layer service, and the seamless connection with the bottom layer service of the local language structure is achieved.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the embodiments or the prior art descriptions will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.
Fig. 1 is a schematic diagram illustrating a system architecture of an open system architecture of an automobile provided according to an embodiment of the present application;
FIG. 2 illustrates a schematic diagram of an automotive open system architecture provided in accordance with some embodiments of the present application;
FIG. 3 illustrates a schematic diagram of an open system architecture for an automobile provided in accordance with further embodiments of the present application;
FIG. 4 illustrates a schematic diagram of an open system architecture for an automobile provided in accordance with further embodiments of the present application;
FIG. 5 illustrates a schematic diagram of a data processing method provided in accordance with some embodiments of the present application;
fig. 6 shows a schematic structural diagram of an on-board device provided in an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present application without making any creative effort belong to the protection scope of the present application.
First, terms referred to in the embodiments of the present application are explained and explained.
DDS: a middleware protocol and Application Program Interface (API) standard provides a low latency, high reliability, scalable communication architecture standard for distributed systems. The DDS data sharing takes the Topic of Topic as a unit, and an application program can judge the type of data contained by the application program through the Topic without depending on other context information. Meanwhile, the DDS can automatically store, publish or subscribe data in a user-defined manner, so that the application program can write or read data as if accessing local data.
CAN bus: the data bus in the traditional vehicle-mounted architecture can bear larger data volume, and is a serial communication protocol of ISO international standardization.
LIN (Local Interconnect Network) bus: the data bus in the traditional vehicle-mounted architecture is used for realizing the control of a distributed electronic system in an automobile, can bear smaller data volume, is mainly used for controlling some simple vehicle-mounted equipment, and is an auxiliary bus network.
SOME/IP protocol: is 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 calls, service discovery, and subscription to enable ECU software to communicate with each other.
ARXML (AUTOSAR eXtensible Markup Language): the standard introduces rules for how the AUTOSAR model is serialized into AUTOSAR XML descriptions, providing support for interoperability between AUTOSAR tools.
AUTOSAR: is a consortium dedicated to establishing automobile electronic software standards and developing an open and standardized software architecture for the automobile industry.
Hereinafter, a technical solution of an automobile open system architecture according to an embodiment of the present application will be described in detail with reference to the accompanying drawings.
Fig. 1 is a schematic diagram illustrating a system architecture of an open system architecture of an automobile according to an embodiment of the present application.
Referring to fig. 1, the system architecture of the automotive open system architecture automotive architecture AUTOSAR 110 includes an application layer 110, a runtime environment layer 120, and a base software layer 130, and the application layer 110 and the base software layer 130 communicate with each other through the runtime environment layer 120.
In an example embodiment, the application layer 110 includes at least one application, such as an AUTOSAR software component, an AUTOSAR sensor or actuator component, or the like. The runtime environment layer 120 is a layer that provides communication services for applications. The AUTOSAR software component of the application layer 110 may communicate with other components, such as ECUs or services, through the runtime environment layer 120.
The base software layer 130 mainly includes four parts: microcontroller abstraction layer, ECU abstraction layer, service layer and complex drive. The microcontroller abstraction layer comprises a driver program related to hardware and can be used for accessing a memory, communication, I/O and the like; the ECU abstraction layer is responsible for providing a uniform access interface to realize access to communication, a memory or I/O, so that the resources do not need to be considered to be provided by a microprocessor or external equipment; the service layer provides various types of background services, such as network services, memory management, bus communication services, and the like, and the operating system is located in the service layer.
The complex driver spans from hardware to the runtime environment layer 120, and the main task is to integrate a special purpose non-standard function module, and embed the part of the function into the automotive basic software layer, so as to realize the specific function and time requirement of processing the complex sensor and the actuator. The complex driver is closely related to the single chip and ECU hardware. Its upper program interface is specified and implemented according to AUTOSAR; the lower layer program interface is limited by the standard interface program. The complex drive can realize the evaluation of complex sensors and the control of actuators, such as oil injection control, electromagnetic valve control, incremental position detection and the like.
Fig. 2 illustrates a schematic diagram of an automotive open system architecture provided in accordance with some embodiments of the present application. Hereinafter, the architecture of the open system for an automobile in the exemplary embodiment will be described in detail with reference to the drawings.
Referring to fig. 2, the automobile open system architecture 100 includes a CP (Classic automotive open system architecture) 100, in which: the CP automotive open system architecture 100 comprises a DDS protocol stack component 132, and the DDS protocol stack component 132 is integrated in the CP automotive open system architecture in a complex driver form.
The CP automotive interacts directly with the sensors and actuators by extracting the peripherals of the microcontroller as signals that can be used by the application to process the input/output values of the sensors/actuators and to send and receive bus data. The CP AUTOSAR connects vehicle network communication interfaces such as LIN bus, CAN bus, and ethernet. The CP automotive also supports sending and receiving service-oriented resources, such as events, fields, and methods, etc., and the protocol converter in the runtime environment converts the service-oriented protocol interface into a standardized interface.
The Complex Driver (CDD) provides the AUTOSAR interface to the upper layer upwards through the runtime environment layer 120 and directly accesses the MCU (micro controller Unit) registers downwards. In an exemplary embodiment, the CP AUTOSAR application level software component encapsulates and customizes and integrates the DDS protocol stack component 132 in a complex driving form through the communication service of the CP AUTOSAR, for example, the interface of the DDS protocol stack component 132 is encapsulated, the DDS protocol stack component 132 is used as a static link library, and the DDS is used to perform communication between the ECU and the interior of the ECU through a standard API. The DDS is data-centric to accommodate dynamic data from different sources, and applications can interact directly with data in the shared global data space using the DDS protocol stack component 132.
Further, in the exemplary embodiment, DDS protocol stack component 132 includes: the DCPS (Data-Centric Publish-Subscribe) layer 1322 and the DLR (Data Local reconfiguration) layer 1324, the DCPS layer 1322 is used for an application to Publish or Subscribe to a Data object of a target service, and the DLR layer 1324 is used for reconfiguring a Data object of a target service published or subscribed to by an application.
Further, in an example embodiment, the DLR layer 1324 includes an encapsulation module and an index module, the encapsulation module is configured to encapsulate the service provided by the DCPS layer 1322 in the form of a service class, and the service class is generated in the form of a local language structure; the index module is used for establishing a corresponding relation or a mapping relation between the service class and the services corresponding to the DCPS layer.
The DCPS layer 1322 is the core and foundation of the DDS protocol stack component 132, and provides basic services for communication. The encapsulation module in the DLR layer 1324 encapsulates the service provided by the DCPS layer 1322 in the form of a service class, the service class is generated in the form of a local language structure, the service provided by the DCPS layer 1322 is abstracted, and the index module in the DLR layer 1324 establishes a mapping relationship between the service class and the underlying service in the DLR layer 1324. The DLR layer 1324 is established on the basis of the DCPS layer 1322 on the lower layer, and by integrating the service provided by the DCPS layer 1322 into the application layer, the application program can directly perform data interaction with the underlying service, so that the user can directly access the data changed by the underlying service, and the seamless connection with the local language structure is achieved.
According to the technical solution in the example embodiment of fig. 2, on one hand, the DDS protocol stack assembly is encapsulated and customized in a complex driver form and integrated into the CP automotive architecture, and the DDS protocol stack can be integrated into the classic platform automotive architecture; on the other hand, the DLR layer of the DDS protocol stack assembly is established on the basis of the DCPS layer at the lower layer, and by integrating the services provided by the DCPS layer into the application layer, the application program can directly perform data interaction with the bottom layer service, so that a user can directly access the data changed by the bottom layer service, and the seamless connection with the bottom layer service of the local language structure is achieved.
Further, in the exemplary embodiment, DCPS layer 1322 translates both the demand and availability of resources to users into QoS (Quality of Service), which includes a plurality of policy forms, each describing the behavior of a Service by being associated with an assigned name. DCPS layer 1322 provides the functionality of publishing and subscribing to data. Publishing and subscribing through topic association, publishing information through topic association, creating publisher and subscriber entities, and setting QoS parameters for these entities.
For example, the DDS programs the resource availability, the degree of resource occupancy by the provider, and the degree of resource expectation by the requester as topic QoS, publisher QoS, and subscriber QoS, respectively. The QoS parameters virtualize the underlying and overall communication mechanisms, including bandwidth limitations, reliability, latency, and resource limitations, among others. And checking whether the publisher QoS and the subscriber QoS are compatible through the DDS middleware, thereby establishing connection or prompting exception. By controlling the communication process by QoS, the flexibility of communication can be significantly increased.
FIG. 3 illustrates a schematic diagram of an automotive open system architecture provided in accordance with further embodiments of the present application.
Referring to fig. 3, the open system architecture of the automobile further includes an AP (Adaptive Platform) AUTOSAR including a DDS proxy 320, and the DDS protocol stack component of the CP AUTOSAR includes a DDS client 310, where the open system architecture of the CP automobile and the open system architecture of the AP automobile each include an application layer, a runtime environment layer, and a base software layer, and the application layer and the base software layer communicate with each other through the runtime environment layer.
The DDS proxy 320 is configured to communicate with the DDS client 310 through the service interface 330, receive service data of the DDS client 310, and process the service data. The AUTOSAR service interface is typically defined using ARXML, which is a modeling language derived from the AUTOSAR UML meta-model. As a result of the code generation, the ARXML compiler generates code for the proxy and framework for the client and server applications, respectively. At the client, the application instantiates a service instance that is bound to the server running on the proxy. The AUTOSAR service provides the following function call interfaces: the method comprises the following steps of DDS protocol stack initialization, DDS protocol stack period scheduling, DDS protocol stack data sending requests, DDS protocol stack data receiving notifications and DDS protocol stack reverse initialization. Meanwhile, the DDS complex driver provides the following resource parameters: participants (participants) -different communication nodes within the DDS domain, topics (Topic) -specific kinds of data, publishers (publishers) -data producer communication nodes, subscribers (subscribers) -data consumer communication nodes. Different resources are identified by a resource id. And the upper application program example calls a protocol stack interface by using the corresponding resource parameter according to the respective actual functional requirements to realize data interaction in the DDS domain.
According to the example embodiment of fig. 3, on one hand, since the core ECU component of the vehicle-mounted electronic appliance architecture widely adopts a heterogeneous multi-core SOC hardware chip and simultaneously deploys two sets of software architectures, namely, CP AUTOSAR and AP AUTOSAR, and integrates the DDS protocol stack in the CP AUTOSAR through the DDS complex drive by means of the client server architecture of the DDS protocol stack, a DDS communication function can be integrated in a CP real-time core with relatively limited computation power and resources, and a standardized inter-core communication middleware supporting a service-oriented function is realized on a heterogeneous multi-core SOC chip hardware platform; on the other hand, the CP AUTOSAR can improve data processing capability by means of the computation resources of the AP AUTOSAR.
In addition, in an example embodiment, the car open system architecture further includes a static configuration module and a dynamic configuration module, where the static configuration module is configured to configure 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.
In an example embodiment, the DDS protocol stack component of the automobile open system architecture includes 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 an ARXML format, defines a configuration item of the DDS module, and configures the configuration item of the dynamic resource corresponding to the DDS client and the DDS agent. For example, a development tool chain (e.g., vector Davinci) is used to import an ARXML file and set each configuration item of a dynamic resource, and a code generation tool corresponding to the DDS protocol stack component is used to implement dynamic configuration code generation and development tool chain fusion.
According to the technical scheme in the example embodiment, the configuration items of the static resources corresponding to the DDS client and the DDS proxy are configured through the static configuration module; the configuration items of dynamic resources corresponding to the DDS client and the DDS proxy are configured through the dynamic configuration module, seamless integration of a DDS protocol stack on a classic platform AUTOSAR platform can be achieved, the integration scheme can be compatible with CP AUTOSAR standards of various versions, and the integration scheme can be fully fused with a CP AUTOSAR development tool chain and a development flow.
FIG. 4 illustrates a schematic diagram of an automotive open system architecture provided in accordance with further embodiments of the present application.
Referring to fig. 4, the AUTOSAR further includes: a publisher module 410 and a subscriber module 420, the subscriber module 420 being disposed at the CP AUTOSAR application layer, the publisher module 410 being disposed at the AP AUTOSAR application layer, wherein: the publisher module 410 acts as a service provider for providing data objects to the CP automobile open system architecture; the subscriber module 420 acts as a service consumer for obtaining the required data objects from the AP car open system architecture.
Further, in an example embodiment, the DCPS layer further includes a global data space, a physical storage space of the global data space may be located in the shared storage space of the hardware layer 350, and the publisher module 410 is configured to provide the data object to the CP automobile open system architecture through the global data space; the subscriber module 420 is used to obtain the required data objects from the AP car open system architecture through the global data space. The DDS provides an infrastructure for data distribution that ensures correct and efficient delivery of information to the appropriate recipients. The DCPS layer of the DDS establishes a concept of a global data space, and a publisher and a subscriber respectively publish and subscribe data types required by the publisher and the subscriber in the global space, and then transmit the data after the data are processed by a middleware, so that the traditional C/S mode is converted into a service mode taking the data as the center.
According to the technical scheme in the example embodiment of fig. 4, a DCPS layer of a DDS establishes a concept of a global data space, and a publisher and a subscriber publish and subscribe data types required by themselves in the global space, respectively, and perform data transmission after middleware processing, so that a traditional C/S mode is converted into a data-centric service mode, thereby weakening the relationship between the information publisher and the subscriber, removing coupling among various components of the system, enhancing flexibility of the system architecture, and facilitating maintenance and scale expansion of the system.
The following are embodiments of the method of the present application, and for details not disclosed in the embodiments of the method of the present application, please refer to the embodiments of the architecture of the open system of the automobile of the present application.
Fig. 5 illustrates a schematic diagram of a data processing method provided in accordance with some embodiments of the present application.
Referring to fig. 5, the data processing method is applied to an automobile open system architecture, where the automobile open system architecture includes a classic platform CP automobile open system architecture, the CP automobile open system architecture includes a data distribution service DDS protocol stack component, the DDS protocol stack component is integrated in the CP automobile open system architecture in a complex driving form, the DDS protocol stack component includes a DCPS layer and a DLR layer, and the method includes:
In some example embodiments, based on the above solutions, the car open system architecture further includes an adaptive AP car open system architecture, the AP car open system architecture includes a DDS agent, and the method further includes:
and communicating with the DDS client through the service interface of the DDS proxy, receiving the service data of the DDS client and processing the service data.
In some exemplary embodiments, based on the above solution, the automobile open system architecture further includes a static configuration module and a dynamic configuration module, and the method further includes:
configuring, by the static configuration module, configuration items of static resources corresponding to the DDS client and the DDS proxy;
and configuring configuration items of dynamic resources corresponding to the DDS client and the DDS proxy through the dynamic configuration module.
In some example embodiments, based on the above solution, each of the CP automobile open system architecture and the AP automobile open system architecture includes an application layer, a runtime environment layer, and a base software layer, and the application layer and the base software layer communicate with each other through the runtime environment layer.
In some example embodiments, based on the above solution, the automobile open system architecture further includes: a publisher module and a subscriber module, wherein the subscriber module is disposed at the application layer of the CP automobile open system architecture, and the publisher module is disposed at the application layer of the AP automobile open system architecture, and the method further comprises:
providing, by the publisher module, a data object to the CP automobile open system architecture;
and acquiring a required data object from the AP automobile open system architecture through the subscriber module.
In some example embodiments, based on the above scheme, the DCPS layer further includes a global data space, and the method further includes:
the publisher module providing data objects to the CP automobile open system architecture through the global data space;
and the subscriber module acquires a required data object from the AP automobile open system architecture through the global data space.
In some example embodiments, based on the above scheme, the method further comprises:
packaging the services provided by the DCPS layer in a service class form, wherein the service class is generated in a local language structure form; and establishing a corresponding relation between the service class and the services corresponding to the DCPS layer.
According to the technical solution in the exemplary embodiment of fig. 5, on one hand, the DDS protocol stack component is encapsulated and customized in a complex driver form and integrated into the CP AUTOSAR, and the DDS protocol stack can be integrated in the classical AUTOSAR; on the other hand, the DLR layer of the DDS protocol stack assembly is established on the basis of the DCPS layer at the lower layer, and the services provided by the DCPS layer are integrated to the application layer, so that the user can directly access the changed data, and the seamless connection with the local language structure is achieved.
It should be noted that, when the automobile open system architecture provided in the foregoing embodiment executes the automobile open system architecture, only the division of the functional modules is illustrated, and in practical applications, the functions may be distributed by different functional modules according to needs, that is, the internal structure of the device is divided into different functional modules, so as to complete all or part of the functions described above.
In addition, the automobile open system architecture and the data processing method embodiment provided in the above embodiments belong to the same concept, and the embodiment of the implementation process is detailed in the embodiment of the automobile open system architecture, and are not described herein again.
An embodiment of the present application further provides a computer storage medium, where multiple instructions may be stored in the computer storage medium, where the instructions are suitable for being loaded by a processor and for executing the data processing method according to the foregoing embodiment, and a specific execution process may refer to specific descriptions in the foregoing embodiment, which is not described herein again.
An embodiment of the present application further provides a computer program product, where at least one instruction is stored in the computer program product, and the at least one instruction is loaded by the processor and executes the data processing method according to the foregoing embodiment, and a specific execution process may refer to a specific description of the foregoing embodiment, which is not described herein again.
The embodiment of the present application further provides a chip, where the chip is configured to execute the data processing method according to the foregoing embodiment, and specific execution processes may refer to specific descriptions of the foregoing embodiment, which are not described herein again.
In addition, please refer to fig. 6, which provides a schematic structural diagram of an in-vehicle device according to an embodiment of the present application. As shown in fig. 6, the in-vehicle apparatus 600 may include: at least one processor 601, at least one communication module 604, input output interface 603, memory 605, at least one communication bus 602.
Wherein a communication bus 602 is used to enable the connection communication between these components.
The input/output interface 603 may include a Display screen (Display) and a Camera (Camera), and the optional input/output interface 603 may also include a standard wired interface and a standard wireless interface.
The communication module 604 may optionally include a standard wired interface or a wireless interface (e.g., a WIFI interface). The communication module 604 includes a first gateway, e.g., an S2S gateway, that communicates using a first communication protocol, and a second gateway, e.g., a C2C gateway, that communicates using a second communication protocol.
The Memory 605 may include a Random Access Memory (RAM) or a Read-Only Memory (Read-Only Memory). Optionally, the memory 605 includes a non-transitory computer-readable medium. The memory 605 may be used to store an instruction, a program, code, a set of codes, or a set of instructions. The memory 605 may include a stored program area and a stored data area, wherein the stored program area may 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 various method embodiments described above, and the like; the storage data area may store data and the like referred to in the above respective method embodiments. The memory 605 may optionally be at least one storage device located remotely from the processor 601. As shown in fig. 6, the memory 605, which is a kind of computer storage medium, may include therein an operating system, a communication module, an input-output interface module, and a data processing application program.
In the in-vehicle device 600 shown in fig. 6, the input/output interface 603 is mainly used for providing an input interface for a user to obtain data input by the user; and the processor 601 may be used to invoke the data processing application stored in the memory 605 to cause the processor 601 to perform the steps in the data processing method according to various exemplary embodiments of the present disclosure. The in-vehicle device 600 includes an automobile open system architecture including a classic platform CP automobile open system architecture, the CP automobile open system architecture includes a data distribution service DDS protocol stack component, the DDS protocol stack component is integrated in the CP automobile open system architecture in a complex driving form, the DDS protocol stack component includes a DCPS layer and a DLR layer, for example, the processor 601 may execute the steps shown in fig. 5: step 510, receiving a data object of a target service published or subscribed by an application program through the DCPS layer; and step 520, reconstructing the data object of the target service published or subscribed by the application program through the DLR layer.
The foregoing is a schematic view of an in-vehicle device according to an embodiment of this specification, and the in-vehicle device may be a central gateway, or may also be other suitable devices, for example, an in-vehicle gateway. It should be noted that the technical solution of the vehicle-mounted device and the technical solution of the vehicle open system architecture belong to the same concept, and details that are not described in detail in the technical solution of the vehicle-mounted device can be referred to the description of the technical solution of the vehicle open system architecture processing method.
In the description of the present application, it is to be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. In the description of the present application, it is noted that, unless explicitly stated or limited otherwise, "including" and "having" and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements but may alternatively include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus. The specific meaning of the above terms in this application will be understood to be a specific case for those of ordinary skill in the art. Further, in the description of the present application, "a plurality" means two or more unless otherwise specified. "and/or" describes the association relationship of the associated object, indicating that there may be three relationships, for example, a and/or B, which may indicate: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.
It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by a computer program, which can be stored in a computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. The storage medium may be a magnetic disk, an optical disk, a read-only memory or a random access memory.
The above disclosure is only for the purpose of illustrating the preferred embodiments of the present application and should not be taken as limiting the scope of the present application, so that the present application will be covered by the appended claims.
Claims (10)
1. An automobile open system architecture, characterized in that 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, and the DDS protocol stack component is integrated in the CP automobile open system architecture in a complex driving form;
the DDS protocol stack assembly comprises: the data-centric publishing and subscribing layer is used for publishing or subscribing a data object of a target service by an application program, and the data local reconstruction layer is used for reconstructing the data object of the target service published or subscribed by the application program.
2. The car open system architecture of claim 1, wherein the DDS protocol stack component comprises a DDS client, the car open system architecture further comprising an adaptive AP car open system architecture, the AP car open system architecture comprising a DDS agent,
the DDS agent 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 vehicle open system architecture according to claim 2, further comprising 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 the configuration items of the dynamic resources corresponding to the DDS client and the DDS proxy.
4. The car open system architecture of claim 2, wherein the CP car open system architecture and the AP car open system architecture each comprise an application layer, a runtime environment layer, and a base software layer, and the application layer and the base software layer communicate with each other through the runtime environment layer.
5. The car open system architecture according to claim 4, further comprising: a publisher module and a subscriber module, wherein the subscriber module is disposed in the application layer of the CP automobile open system architecture, and the publisher module is disposed in 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;
and the subscriber module is used for acquiring required data objects from the AP automobile open system architecture.
6. The automobile open system architecture of 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 data objects to the CP automobile open system architecture through the global data space;
and the subscriber module is used for acquiring required data objects from the AP automobile open system architecture through the global data space.
7. The car open system architecture according to any one of claims 1 to 6, wherein the data local reconstruction layer comprises an encapsulation module and an indexing module, wherein:
the packaging module is used for packaging the services provided by the publish-subscribe layer in a service class form, and the service class is generated in a local language structure form;
the index module is used for establishing the corresponding relation between the service class and the service corresponding to the publish-subscribe layer.
8. A data processing method applied to the open system architecture of the automobile according to any one of claims 1 to 7, the method comprising:
receiving a data object of a target service published or subscribed by an application program through the publishing and subscribing layer;
and reconstructing the data object of the target service published or subscribed by the application program through a data local reconstruction layer.
9. A computer storage medium having stored thereon a plurality of instructions adapted to be loaded by a processor and to carry out the steps of the method according to claim 8.
10. An in-vehicle apparatus characterized by comprising: a processor and a memory, the memory storing a computer program adapted to be loaded by the processor and to perform the steps of the method according to claim 8.
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211352867.4A CN115766915A (en) | 2022-11-01 | 2022-11-01 | Automobile open system architecture, data processing method, medium and vehicle-mounted equipment |
| PCT/CN2023/126206 WO2024093731A1 (en) | 2022-11-01 | 2023-10-24 | Automotive open system architecture, data processing method and on-board device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211352867.4A CN115766915A (en) | 2022-11-01 | 2022-11-01 | Automobile open system architecture, data processing method, medium and vehicle-mounted equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115766915A true CN115766915A (en) | 2023-03-07 |
Family
ID=85354930
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211352867.4A Pending CN115766915A (en) | 2022-11-01 | 2022-11-01 | Automobile open system architecture, data processing method, medium and vehicle-mounted equipment |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN115766915A (en) |
| WO (1) | WO2024093731A1 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024093731A1 (en) * | 2022-11-01 | 2024-05-10 | 长城汽车股份有限公司 | Automotive open system architecture, data processing method and on-board device |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105205183B (en) * | 2015-10-29 | 2018-06-22 | 哈尔滨工业大学 | A kind of DDS distributed system method for auto constructing based on XML |
| US10530793B2 (en) * | 2016-06-29 | 2020-01-07 | Argus Cyber Security Ltd. | System and method for detection and prevention of attacks on in-vehicle networks |
| US11321442B2 (en) * | 2020-03-20 | 2022-05-03 | Infineon Technologies Ag | Data link layer authenticity and security for automotive communication system |
| CN112104536B (en) * | 2020-11-02 | 2021-02-12 | 奥特酷智能科技(南京)有限公司 | Automobile Ethernet bus design method based on DDS protocol |
| CN115242565B (en) * | 2021-04-22 | 2023-12-15 | 华为技术有限公司 | System architecture, communication method and equipment for realizing DDS communication based on AUTOSAR |
| CN114172938B (en) * | 2022-02-10 | 2022-05-20 | 诚迈科技（南京）股份有限公司 | Method and system for realizing SOA (service oriented architecture) of intelligent cabin and intelligent automobile |
| CN115766915A (en) * | 2022-11-01 | 2023-03-07 | 长城汽车股份有限公司 | Automobile open system architecture, data processing method, medium and vehicle-mounted equipment |
-
2022
- 2022-11-01 CN CN202211352867.4A patent/CN115766915A/en active Pending
-
2023
- 2023-10-24 WO PCT/CN2023/126206 patent/WO2024093731A1/en unknown
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2024093731A1 (en) * | 2022-11-01 | 2024-05-10 | 长城汽车股份有限公司 | Automotive open system architecture, data processing method and on-board device |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2024093731A1 (en) | 2024-05-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Fürst et al. | AUTOSAR for connected and autonomous vehicles: The AUTOSAR adaptive platform | |
| Chen et al. | Android/OSGi-based vehicular network management system | |
| Im et al. | IoT mashup as a service: cloud-based mashup service for the Internet of things | |
| CN105183452B (en) | Spring AOP-based remote protocol service system for monitoring power distribution equipment | |
| Yoong et al. | IEC 61499 in a Nutshell | |
| WO2024093731A1 (en) | Automotive open system architecture, data processing method and on-board device | |
| WO2022222901A1 (en) | System architecture for implementing dds communication on basis of autosar, communication method, and device | |
| Jan et al. | Flex‐eWare: a flexible model driven solution for designing and implementing embedded distributed systems | |
| Kim et al. | A generic Internet of things (IoT) platform supporting plug-and-play device management based on the semantic web | |
| WO2024093674A1 (en) | Vehicle-to-cloud communication method and apparatus, storage medium, and vehicle-mounted communication device | |
| Tommila et al. | Next generation of industrial automation | |
| CN111443963A (en) | Numerical control system of reconfigurable formula | |
| Weckemann et al. | Lessons from a Minimal Middleware for IP-based In-car Communication | |
| CN109669793B (en) | Object calling method in middleware process | |
| CN113886731A (en) | Method for routing page jump based on iOS platform and application | |
| Yim et al. | A Ubiquitous Web Services framework for interoperability in pervasive environments | |
| Marin et al. | Sensor bean: a component platform for sensor-based services | |
| Aguirre et al. | MCSARCH: An architecture for the development of manufacturing control systems | |
| Kaliski | Multi-tenant cloud computing: From cruise liners to container ships | |
| Singh et al. | Implementing Adaptive AUTOSAR Diagnostic Manager with Classic Diagnostics as APIs | |
| CN116996551B (en) | Vehicle-mounted service control system and method based on SOA central network controller | |
| Thramboulidis et al. | Field device specification for the development of function block oriented engineering support systems | |
| Trevathan et al. | A unique solution for designing low-Cost, heterogeneous sensor networks using a middleware integration platform | |
| Mihajlović et al. | Challenges of Integrating Machine Vision Algorithms Based on Franca IDL into Adaptive AUTOSAR Environment | |
| Trifunović et al. | Data Exchange Interfaces in Automotive SOA |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |