A service-oriented architecture system, service method, device, equipment and medium

Abstract

The application relates to the technical field of vehicle hardware data processing, and discloses a service-oriented architecture system, a service method, an apparatus, a device and a medium. The system comprises a data layer, the data layer comprising hardware data of various controllers of the vehicle; a packaging service unit, the packaging service unit being used for acquiring various hardware data from the data layer and packaging the various hardware data into multiple different service interfaces according to different characteristics among the various hardware data; an application implementation environment layer, the application implementation environment layer being used for acquiring various service interfaces from the packaging service unit based on an interface transmission protocol and storing the various service interfaces; and an application layer, the application layer being used for calling a target service interface from the application implementation environment layer and acquiring target hardware data packaged in the target service interface according to a target address identifier of the target service interface. The application can reduce the development complexity of a software architecture and improve development efficiency.

Description

Technical Field

[0001] This application relates to the field of vehicle hardware data processing technology, and in particular, to a service-oriented architecture system, service method, apparatus, device, and medium. Background Technology

[0002] With the continuous updates and iterations of vehicle ECUs (Electronic Control Units), the number of hardware registers has increased significantly, resulting in a greater volume of hardware data available from the ECU and tighter business coupling. In existing processing systems, an I / O abstraction layer or other specialized applications are often used to process hardware data, which is then sent to functional domain applications via an intermediate layer. This approach requires designing upper-layer applications for hardware data processing. Different developers will design different architectures and corresponding hardware data processing logic, leading to non-standardized interface development and architecture design. This results in poor software development efficiency and necessitates additional functional safety assessments and designs, as data security during transmission cannot be adequately guaranteed. Summary of the Invention

[0003] This application provides a service-oriented architecture (SOA) system, service method, apparatus, device, and medium. By encapsulating service units, various hardware data are packaged into multiple different service interfaces based on their varying characteristics. The application implementation environment layer then retrieves and stores these service interfaces from the encapsulated service units based on an interface transmission protocol. In the application implementation environment layer, all service interfaces undergo security verification, eliminating the need for developers to repeatedly perform functional safety assessments and designs on the acquired hardware data. Furthermore, by encapsulating hardware data into multiple different service interfaces, standardized design for service interface development is possible within existing SOA architectures. Developers can iterate using existing service interfaces without requiring application-layer design, reducing software development complexity and improving development efficiency.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, a service-oriented architecture system for a vehicle is provided, the system comprising:

[0006] The data layer includes the hardware data of each controller of the vehicle;

[0007] An encapsulation service unit is used to obtain various hardware data from the data layer and encapsulate each hardware data into multiple different service interfaces according to the different characteristics between the various hardware data. Each service interface corresponds to hardware data with at least one characteristic. Each service interface has an address identifier, and the address identifier has a corresponding relationship with the data address of the hardware data encapsulated in the service interface.

[0008] The application implementation environment layer is used to obtain and store each of the service interfaces from the encapsulated service unit based on the interface transmission protocol.

[0009] The application layer is used to call the target service interface from the application implementation environment layer, and obtain the target hardware data encapsulated in the target service interface according to the target address identifier of the target service interface.

[0010] In one embodiment of this application, based on the foregoing scheme, the system further includes a protocol layer, which is used to obtain each of the service interfaces from the encapsulation service unit, and the application implementation environment layer can obtain and store each of the service interfaces from the protocol layer based on the interface transmission protocol.

[0011] In one embodiment of this application, based on the foregoing scheme, the encapsulation service unit includes: a data acquisition unit and a data processing unit. The data acquisition unit is used to acquire various hardware data from the data layer and transmit each hardware data to the data processing unit. The data processing unit is used to classify and process the hardware data according to its characteristics to obtain processed target data.

[0012] In one embodiment of this application, based on the foregoing scheme, the encapsulation service unit further includes an encapsulation unit, which is used to encapsulate each of the target data into each of the service interfaces, define the functions based on the hardware characteristics of each target data, and transmit the defined service interfaces to the protocol layer.

[0013] In one embodiment of this application, based on the foregoing scheme, the data processing unit is further configured to classify each piece of hardware data into IO data and register data, and perform secondary classification based on the data characteristics of each IO data and the hardware characteristics of each register data to obtain each piece of target data; the encapsulation unit is further configured to encapsulate different types of service interfaces according to each piece of target data after secondary classification to obtain a first type of service interface, a second type of service interface, and a third type of service interface; wherein, the first type of service interface, the second type of service interface, and the third type of service interface all correspond to different processing logics, and each of the first type of service interface, the second type of service interface, and the third type of service interface includes multiple service interfaces.

[0014] In one embodiment of this application, based on the foregoing scheme, when the application layer calls the service interface, it obtains the service interface type corresponding to the service interface, obtains the hardware data corresponding to the service interface according to the address identifier of the service interface, and processes the hardware data according to the processing logic corresponding to the service interface type.

[0015] According to one aspect of the embodiments of this application, a service method for a service-oriented architecture is also provided. The method is executed on an encapsulated service unit in a service-oriented architecture service system as provided in the above embodiments. The method includes:

[0016] Obtain hardware data from each controller in the data layer;

[0017] Based on the different characteristics of each piece of hardware data, each piece of hardware data is encapsulated into multiple different service interfaces. Each service interface corresponds to at least one type of hardware data with different characteristics. Each service interface has an address identifier, and there is a correspondence between the address identifier and the data address of the hardware data encapsulated within the service interface.

[0018] Based on the interface transmission protocol, each of the service interfaces is transmitted to the application implementation environment layer so that the application implementation environment layer can store each of the service interfaces for the application layer to call the target service interface.

[0019] According to one aspect of the embodiments of this application, a service apparatus for a service-oriented architecture is provided. The apparatus includes: an acquisition unit for acquiring hardware data of various controllers in a data layer; an encapsulation unit for encapsulating the hardware data into multiple different service interfaces based on the different characteristics of the hardware data, each service interface corresponding to hardware data with at least one characteristic, each service interface having an address identifier, and the address identifier having a correspondence with the data address of the hardware data encapsulated within the service interface; and a transmission unit for transmitting the service interfaces to an application implementation environment layer based on an interface transmission protocol, so that the application implementation environment layer stores the service interfaces for the application layer to call target service interfaces.

[0020] According to one aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, the computer program including executable instructions that, when executed by a processor, implement the service method of the service-oriented architecture as described in the above embodiments.

[0021] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a memory for storing executable instructions of the processors, wherein when the executable instructions are executed by the one or more processors, the one or more processors implement the service method of the service-oriented architecture as described in the above embodiments.

[0022] In the technical solution of this application embodiment, a packaging service unit can encapsulate the various hardware data into multiple different service interfaces based on their different characteristics. The application implementation environment layer then obtains and stores these service interfaces from the packaging service unit based on an interface transmission protocol. In the application implementation environment layer, all service interfaces undergo security verification, eliminating the need for developers to repeatedly perform functional safety assessments and designs on the acquired hardware data. Furthermore, by encapsulating the hardware data into multiple different service interfaces, standardized design of service interface development is possible within the existing SOA architecture. Developers can iterate using existing service interfaces without needing to design the application layer, reducing software development complexity and improving development efficiency.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0025] Figure 1 This is a flowchart illustrating a service method based on a service-oriented architecture according to an embodiment of this application;

[0026] Figure 2 This is a specific block diagram of a service system with a service-oriented architecture according to an embodiment of this application;

[0027] Figure 3 This is a block diagram illustrating a service apparatus for a service-oriented architecture according to embodiments of this application;

[0028] Figure 4 This is a schematic diagram of the system structure of an electronic device according to an embodiment of this application;

[0029] Figure 5 This is a schematic diagram illustrating various service interface types according to embodiments of this application. Detailed Implementation

[0030] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0031] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0032] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller node devices.

[0033] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0034] It should be noted that "multiple" in this article refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0035] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0036] First, it should be noted that the service-oriented architecture proposed in the embodiments of this application can be applied to the technical field of vehicle hardware data processing. The current problem with existing technologies is that hardware data obtained from the data layer through the IO abstraction layer in the existing AutoSAR software architecture is processed. After processing, functional design of the application layer is still required so that the application layer can read the processed hardware data. Therefore, developers need to design and develop interfaces for the application layer and the corresponding IO abstraction layer. The development structure is non-standardized, and each different developer has different development standards. Consequently, the reusability of the developed architecture is poor.

[0037] In this embodiment, by adopting the functionality of SOA architecture, the acquired hardware data is encapsulated into service interfaces to ensure standardization during the development process. This allows different developers to achieve standardization through the encapsulation of service interfaces when developing software, reducing the efficiency of subsequent developers when improving or upgrading the architecture. After the service interface is transmitted to the application implementation environment layer, the application implementation environment layer can perform functional safety verification on the service interface, so developers do not need to perform security verification on the hardware data again.

[0038] According to one aspect of this application, a service-oriented architecture system for a vehicle is provided, the system comprising:

[0039] The data layer includes the hardware data of each controller of the vehicle;

[0040] An encapsulation service unit is used to obtain various hardware data from the data layer and encapsulate each hardware data into multiple different service interfaces according to the different characteristics between the various hardware data. Each service interface corresponds to hardware data with at least one characteristic. Each service interface has an address identifier, and the address identifier has a corresponding relationship with the data address of the hardware data encapsulated in the service interface.

[0041] The application implementation environment layer is used to obtain and store each of the service interfaces from the encapsulated service unit based on the interface transmission protocol.

[0042] The application layer is used to call the target service interface from the application implementation environment layer, and obtain the target hardware data encapsulated in the target service interface according to the target address identifier of the target service interface.

[0043] Specifically, please refer to Figure 2 As shown, Figure 2 This is a framework diagram of the entire system provided in the embodiments of this application, wherein the Hardware layer is the data layer described in the embodiments of this application, HwDataAbstr is the encapsulation service unit described in this application, BSW is the protocol layer, RTE is the application implementation environment layer, SWC A and SWC B are both application layers, Coord is the data acquisition unit described in this application, Alog / Classify is the data processing unit, and Adapt is the encapsulation unit.

[0044] Based on the different characteristics of each piece of hardware data, each piece of hardware data is encapsulated into multiple different service interfaces. Each service interface corresponds to at least one type of hardware data with different characteristics. In other words, the hardware data with various characteristics is classified into major categories and minor categories. For example, the major category can be divided into vehicle body domain functions, and the minor category can be divided into various functional categories under the vehicle body domain functions, such as windows, doors, etc. By encapsulating these hardware data with different functional characteristics into service interfaces with different characteristics, when the corresponding data needs to be called, the target hardware data encapsulated in the target service interface can be obtained directly by calling the corresponding target service interface.

[0045] In one embodiment of this application, the system further includes a protocol layer, which is used to obtain each of the service interfaces from the encapsulation service unit. The application implementation environment layer can obtain each of the service interfaces from the protocol layer based on the interface transmission protocol and store them.

[0046] Specifically, the protocol layer only has transmission functions and does not process the encapsulated service interfaces.

[0047] In one embodiment of this application, the encapsulation service unit includes a data acquisition unit and a data processing unit. The data acquisition unit is used to acquire various hardware data from the data layer and transmit the hardware data to the data processing unit. The data processing unit is used to classify and process the hardware data according to its characteristics to obtain processed target data. The encapsulation service unit further includes an encapsulation unit, which is used to encapsulate each target data into a service interface, define its functionality based on the hardware characteristics of each target data, and transmit the defined service interfaces to the protocol layer.

[0048] Specifically, the data acquisition unit collects hardware data, the data processing unit classifies and processes it using common algorithms, and the encapsulation unit encapsulates and virtualizes various hardware data into Someip service interfaces, which include three service types: Method, Event, and Field, enabling cross-core communication and interaction with multi-core system application providers (SWC).

[0049] The data processing unit is further configured to classify the various hardware data into IO data and register data, and perform secondary classification based on the data characteristics of each IO data and the hardware characteristics of each register data to obtain various target data; the encapsulation unit is further configured to encapsulate different types of service interfaces according to the secondary classified target data to obtain a first type of service interface, a second type of service interface and a third type of service interface; wherein, the first type of service interface, the second type of service interface and the third type of service interface all correspond to different processing logic, and each of the first type of service interface, the second type of service interface and the third type of service interface includes multiple service interfaces.

[0050] Method, Event, and Field refer to the first, second, and third types of service interfaces described in the embodiments of this application. Each type of service interface may include multiple service interfaces, and the corresponding interface functions may be as follows: Figure 5 As shown, Method is used to execute a service command, and you can choose whether to pay attention to the service result. For example, to turn on the headlights, you can choose not to pay attention to whether they are already turned on and just perform the operation, or you can pay attention to whether the headlights are already turned on and record it in the system to remind the driver whether the headlights have been turned on.

[0051] The service interface corresponding to Event is used for prompting certain functions, while Field is used to execute certain function instructions. Taking the acquisition of power supply voltage for ECU power management as an example, the raw value of the voltage ADC is acquired and processed using common de-jitter filtering algorithms (amplitude limiting filtering method / median value filtering method / recursive average filtering method). The platform is designed to provide multiple algorithm processing for power supply voltages Va / Vb / Vc. Commonly used voltages are periodically notified to the application layer in the form of Event, while uncommon voltages are obtained by the application as needed in the form of Get Field.

[0052] When the application layer calls the service interface, it obtains the service interface type corresponding to the service interface, obtains the hardware data corresponding to the service interface according to the address identifier of the service interface, and processes the hardware data according to the processing logic corresponding to the service interface type.

[0053] Hardware data can be categorized into I / O data and register data. Different types of hardware data require different processing logic. Therefore, different target data can be functionally defined in the encapsulation unit. Subsequently, the application layer can retrieve the data according to the defined processing logic when calling the service interface.

[0054] (1) IO Data: Taking the power supply voltage acquisition for ECU power management as an example, the virtualization module of this solution acquires the raw value of the voltage ADC and processes it using common de-jitter filtering algorithms (amplitude limiting filtering / median value filtering / recursive average filtering). The platform is designed to provide multiple algorithms for processing power supply voltages Va / Vb / Vc. Commonly used voltages are periodically notified to the upper layer in the form of Events, while uncommon voltages are obtained by the application on demand in the form of Get Fields. Through the above method, hardware data IO data is integrated in the early stage of ECU development. Based on development experience, corresponding common service interfaces are designed, and the acquisition / writing cycle and filtering algorithm are specified. The application layer dynamically acquires / provides services according to the business requirements.

[0055] (2) Register Data: With the increasing demands for functional safety in chip and peripheral device safety, register data is becoming increasingly coupled with business logic during product development. This solution integrates commonly used ECU registers (STM / RTC / GPT, etc.) and fault registers (MMFSR / HFSR), and serializes the data provided by the hardware adaptation layer into SomeIP service groups. Through this abstraction of register data, applications can focus more on actual business requirements without distinguishing between the crystal oscillators and addresses of different registers, minimizing the impact of hardware and register changes.

[0056] This invention eliminates the need for security design at the application layer. Once the ECU hardware is virtualized as a SomeIP service, it interacts with the RTE layer via the LdCom module, leveraging AutoSAR's inter-core communication (IOC) and RTE-specific domain protection to ensure the security of its hardware data transmission link. The hardware data transmission method across multiple cores is consistent with AutoSAR SWC inter-core communication, achieving a high level of functional safety.

[0057] In ECU embedded software development, the application side relies heavily on hardware information from the chip datasheet when processing hardware data, resulting in significant disadvantages in standardization, generalization, and data protection. This invention's technical solution combines SOA software design concepts with a data virtualization module, effectively improving software development speed and security, enhancing the company's product competitiveness; it also achieves software and hardware platformization, improving software product portability and reducing product development costs.

[0058] First, it accelerates development speed: When an application adds a new requirement for hardware data, additional software modules need to be developed to process the data in order to adapt to the application interface, which affects the development iteration speed. Using the technical solution of this invention, development is carried out based on the AutoSAR standard SomeIP service interface. The application software development process can call standardized service functions, which helps to facilitate parallel development and rapid integration of various functional domains and improves the iteration speed of software products.

[0059] Secondly, it offers high security: In a multi-core operating system, each core corresponds to an application layer as described in this application, and hardware I / O and register processing require strict consideration of data reentrancy and cross-core data protection. Based on this design, the RTE data protection and interface reentrancy queue of the AutoSAR architecture can be utilized, ultimately achieving a high level of functional safety and improving software development security.

[0060] Platform-based solution, adaptable to external needs and hardware changes: Traditional solutions require application layer design to consider hardware data read / write, and the software architecture is redesigned repeatedly after chip switching. This solution transfers hardware data processing through the BSW layer, SomeIP, and RTE layer, decoupling the software interface and hardware link to achieve isolation. This eliminates the need to change the application implementation environment layer and application layer architecture; only the encapsulated service units need to be rewritten, resulting in a highly versatile architecture.

[0061] According to one aspect of this application, a service approach based on a service-oriented architecture is provided. Figure 1 The flowchart illustrates a service method for a service-oriented architecture according to an embodiment of this application. This vehicle service capability verification method is executed within an encapsulated service unit in the aforementioned service-oriented architecture system. The method includes at least steps 110 to 130, detailed below:

[0062] In step 110, the hardware data of each controller in the data layer is obtained.

[0063] Specifically, each controller is a separate ECU, or Electronic Control Unit. Each piece of hardware data possesses different characteristics. These hardware data are encapsulated into multiple different service interfaces. Each service interface corresponds to at least one type of hardware data with different characteristics. This means the hardware data with various characteristics is categorized into major and minor categories. For example, major categories can be divided into vehicle body domain functions, and minor categories can be further divided into various functional classifications within the vehicle body domain, such as windows, doors, etc. By encapsulating these hardware data with different functional characteristics into service interfaces of different characteristics, when the corresponding data needs to be called, the target hardware data encapsulated within the target service interface can be obtained directly by calling the corresponding target service interface.

[0064] In step 120, based on the different characteristics of each piece of hardware data, each piece of hardware data is encapsulated into multiple different service interfaces. Each service interface corresponds to at least one type of hardware data with different characteristics. Each service interface has an address identifier, and the address identifier corresponds to the data address of the hardware data encapsulated within the service interface.

[0065] Specifically, when the application layer calls the target service interface, it can obtain the corresponding target hardware data through the data address of the hardware data encapsulated within the target service interface. The target hardware data can also be service data after virtualization processing, corresponding to the service interface.

[0066] In step 130, each of the service interfaces is transmitted to the application implementation environment layer based on the interface transmission protocol, so that the application implementation environment layer can store each of the service interfaces for the application layer to call the target service interface.

[0067] Specifically, the protocol layer can transmit each of the service interfaces to the application implementation environment layer through the interface transmission protocol, so that the application implementation environment layer can store each of the service interfaces for the application layer to call the target service interface.

[0068] In summary, in the technical solution of this application embodiment, the encapsulation service unit can encapsulate the various hardware data into multiple different service interfaces based on their different characteristics. The application implementation environment layer then obtains and stores these service interfaces from the encapsulation service unit based on the interface transmission protocol. In the application implementation environment layer, all service interfaces pass security verification, thus eliminating the need for developers to repeatedly perform functional safety assessments and designs on the acquired hardware data. Furthermore, by encapsulating the hardware data into multiple different service interfaces, standardized design of service interface development can be achieved within the existing SOA architecture. Developers can iterate using existing service interfaces without needing to design the application layer, reducing software development complexity and improving development efficiency.

[0069] Figure 3 This is a block diagram illustrating a service device 300 with a service-oriented architecture according to an embodiment of this application. The service device 300 with a service-oriented architecture according to an embodiment of this application includes: an acquisition unit 301, an encapsulation unit 302, and a transmission unit 303.

[0070] Acquisition unit 301 is used to acquire hardware data of each controller in the data layer;

[0071] The encapsulation unit 302 is used to encapsulate the hardware data into multiple different service interfaces according to the different characteristics between the hardware data. Each service interface corresponds to hardware data with at least one characteristic. Each service interface has an address identifier, and the address identifier has a corresponding relationship with the data address of the hardware data encapsulated in the service interface.

[0072] The transmission unit 303 is used to transmit each of the service interfaces to the application implementation environment layer based on the interface transmission protocol, so that the application implementation environment layer can store each of the service interfaces for the application layer to call the target service interface.

[0073] In another aspect, this application also provides a computer-readable storage medium storing a program product capable of implementing the methods provided above in this specification. In some possible implementations, various aspects of this application may also be implemented as a program product comprising program code that, when run on a terminal device, causes the terminal device to perform the steps described in the "Embodiment Methods" section of this specification according to various exemplary embodiments of this application.

[0074] The program product for implementing the above-described method according to the embodiments of this application may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of this application is not limited thereto. In this document, the readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0075] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0076] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0077] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0078] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0079] In another respect, this application also provides an electronic device capable of implementing the above-described method.

[0080] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0081] The following reference Figure 4 To describe an electronic device 400 according to this embodiment of the present application. Figure 4 The electronic device 400 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0082] like Figure 4 As shown, the electronic device 400 is manifested in the form of a general-purpose computing device. The components of the electronic device 400 may include, but are not limited to: at least one processing unit 410, at least one storage unit 420, and a bus 430 connecting different system components (including storage unit 420 and processing unit 410).

[0083] The storage unit stores program code that can be executed by the processing unit 410, causing the processing unit 410 to perform the steps described in the "Embodiment Methods" section above according to various exemplary embodiments of this application.

[0084] Storage unit 420 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 421 and / or cache memory 422, and may further include a read-only memory (ROM) 423.

[0085] Storage unit 420 may also include a program / utility 424 having a set (at least one) of program modules 425, such program modules 425 including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0086] Bus 430 can represent one or more of several types of bus structures, including a memory cell bus or memory cell control node, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0087] Electronic device 400 can also communicate with one or more external devices 1200 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 400, and / or with any device that enables electronic device 400 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 450. Furthermore, electronic device 400 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 460. As shown, network adapter 460 communicates with other modules of electronic device 400 via bus 430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 400, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0088] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the method according to the embodiments of this application.

[0089] Furthermore, the above figures are merely illustrative of the processes included in the method according to exemplary embodiments of this application, and are not intended to be limiting. It is readily understood that the processes shown in the above figures do not indicate or limit the temporal order of these processes. Additionally, it is readily understood that these processes may be executed synchronously or asynchronously, for example, in multiple modules.

[0090] It should be understood that this application is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A service-oriented architecture system for vehicles, characterized in that, The system includes: The data layer includes the hardware data of each controller of the vehicle; An encapsulation service unit is used to obtain various hardware data from the data layer and encapsulate each hardware data into multiple different service interfaces according to the different characteristics between the various hardware data. Each service interface corresponds to hardware data with at least one characteristic. Each service interface has an address identifier, and the address identifier has a corresponding relationship with the data address of the hardware data encapsulated in the service interface. The application implementation environment layer is used to obtain and store each of the service interfaces from the encapsulated service unit based on the interface transmission protocol. The application layer is used to call the target service interface from the application implementation environment layer, and obtain the target hardware data encapsulated in the target service interface according to the target address identifier of the target service interface.

2. The system according to claim 1, characterized in that, The system also includes a protocol layer, which is used to obtain each of the service interfaces from the encapsulation service unit. The application implementation environment layer can obtain each of the service interfaces from the protocol layer based on the interface transmission protocol and store them.

3. The system according to claim 2, characterized in that, The encapsulation service unit includes a data acquisition unit and a data processing unit. The data acquisition unit is used to acquire various hardware data from the data layer and transmit each hardware data to the data processing unit. The data processing unit is used to classify and process the hardware data according to its characteristics to obtain the processed target data.

4. The system according to claim 3, characterized in that, The encapsulation service unit further includes an encapsulation unit, which is used to encapsulate each of the target data into each of the service interfaces, define the functions based on the hardware characteristics of each target data, and transmit the defined service interfaces to the protocol layer.

5. The system according to claim 4, characterized in that, The data processing unit is also used to classify each piece of hardware data into I / O data and register data, and to perform secondary classification based on the data characteristics of each piece of I / O data and the hardware characteristics of each piece of register data to obtain each piece of target data. The encapsulation unit is further configured to encapsulate different types of service interfaces according to the target data after secondary classification, so as to obtain a first type of service interface, a second type of service interface and a third type of service interface; wherein the first type of service interface, the second type of service interface and the third type of service interface all correspond to different processing logic, and the first type of service interface, the second type of service interface and the third type of service interface all include multiple service interfaces.

6. The system according to claim 5, characterized in that, When the application layer calls the service interface, it obtains the service interface type corresponding to the service interface, obtains the hardware data corresponding to the service interface according to the address identifier of the service interface, and processes the hardware data according to the processing logic corresponding to the service interface type.

7. A service-oriented architecture approach, characterized in that, The method is performed on the encapsulation service unit as described in any one of claims 1-6, and the method includes: Obtain hardware data from each controller in the data layer; Based on the different characteristics of each piece of hardware data, each piece of hardware data is encapsulated into multiple different service interfaces. Each service interface corresponds to at least one type of hardware data with different characteristics. Each service interface has an address identifier, and there is a correspondence between the address identifier and the data address of the hardware data encapsulated within the service interface. Based on the interface transmission protocol, each of the service interfaces is transmitted to the application implementation environment layer so that the application implementation environment layer can store each of the service interfaces for the application layer to call the target service interface.

8. A service apparatus for a service-oriented architecture, characterized in that, The device includes: The acquisition unit is used to acquire hardware data from each controller in the data layer. An encapsulation unit is used to encapsulate the various hardware data into multiple different service interfaces according to the different characteristics between the various hardware data. Each service interface corresponds to hardware data with at least one characteristic. Each service interface has an address identifier, and the address identifier has a corresponding relationship with the data address of the hardware data encapsulated in the service interface. The transmission unit is used to transmit each of the service interfaces to the application implementation environment layer based on the interface transmission protocol, so that the application implementation environment layer can store each of the service interfaces for the application layer to call the target service interface.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one piece of program code, which is loaded and executed by a processor to perform the operations described in claim 7.

10. An electronic device, characterized in that, The electronic device includes one or more processors and one or more memories, wherein at least one piece of program code is stored in the one or more memories, and the at least one piece of program code is loaded and executed by the one or more processors to perform the operation performed by the method as described in claim 7.

Images