General software communication bus

Abstract

Methods and systems for apparatus for a communication control system are provided. In one example, the apparatus includes a distributed component interconnect framework (DCIF) configured to enable communication between different software modules of a communication network based on already existing code. The DCIF allows for simultaneous communication between multiple transport protocols.

Description

Technical Field

[0001] This disclosure relates to a communication bus for various applications such as audio, video, and automotive. Background Technology

[0002] Software buses can be used to facilitate connections and communication between software modules. They can act as communication bridges within, for example, electronic control units (ECUs), operating systems (OS), or computing processes in a vehicle. Therefore, software buses enable seamless integration of information and execution between software modules used in systems such as audio systems, video systems, and vehicle systems.

[0003] However, a software bus can be a single transport protocol oriented towards a single system. Therefore, applying a software bus over a network may require writing additional code for each type of transport protocol in the network, as well as when a new client joins. To effectively bridge the various software modules of the network, each bridge software component can be manually coded, increasing the time and effort required to maintain the operation of the software bus. Summary of the Invention

[0004] Implementation schemes for a universal software bus are disclosed. In one example, an apparatus for a communication control system includes a Distributed Component Interconnection Framework (DCIF), which is configured to enable communication between different software modules of a communication network based on existing code. This allows for flexible deployment of software modules across different ECUs, OSes, or processes without rewriting software components when adding new local or remote clients.

[0005] For example, DCIF can abstract the system deployment and cover the entire network, including multiple transport protocols, and can also avoid multiple hand-coded bridge software components by allowing point-to-point communication. This approach can be applied to connected vehicles, allowing different software modules of the vehicle's communication control system to communicate without adding new code.

[0006] It should be understood that the above description of the invention is provided to introduce, in a simplified form, a series of concepts that will be further described in the detailed embodiments. This is not intended to identify key or essential features of the claimed subject matter, the scope of which is uniquely defined by the claims following the detailed embodiments. Furthermore, the claimed subject matter is not limited to solutions to any of the deficiencies described above or in any part of this disclosure. Attached Figure Description

[0007] This disclosure can be better understood by referring to the following description of non-limiting embodiments, in which:

[0008] Figure 1A network of systems communicatively connected via a connection module is shown according to one or more embodiments of the present disclosure, the connection module being implemented as a multi-platform software bus;

[0009] Figure 2 A first example of a computing system that can be incorporated into a multi-platform software bus according to one or more embodiments of the present disclosure is illustrated.

[0010] Figure 3 A second example of a computing system that can be incorporated into a multi-platform software bus according to one or more embodiments of the present disclosure is illustrated.

[0011] Figure 4 An example illustration of a multi-platform software bus according to one or more embodiments of the present disclosure is shown; and

[0012] Figure 5 An example of a method for implementing a multi-platform software bus in a communication control system is shown. Detailed Implementation

[0013] Systems and methods for multi-platform software buses are provided. In one example, the software bus can be a generic multi-platform software communication bus (also known as a distributed component interconnect framework or DCIF). DCIF allows communication between networks of systems, such as... Figure 1 As shown. Examples of networks where DCIF can be applied are in... Figure 2 and Figure 3 As shown in the image. Figure 4 The described architecture of DCIF allows DCIF to leverage model-driven development to achieve a higher level of abstraction. The methods used to implement DCIF in communication control systems are... Figure 5 The diagram illustrates a process implemented by DCIF. The methods described in this paper represent an example of a strategy for building secure, multilingual, distributed applications and services. While the example architecture shown in this paper is described, various alternatives, such as those noted herein, can also be used.

[0014] As described in this article, a universal software communication bus (also known as DCIF, Distributed Component Interconnect Framework) can be implemented. DCIF is a technology that allows for the flexible deployment of software modules across different electronic control units (ECUs), operating systems (OS), or processes without rewriting software components when adding new local or remote clients. DCIF also allows for simultaneous communication over different transport protocols, such as Internet Protocol-based Scalable Service-Oriented Middleware (SoME / IP) for automobiles and WebSockets, without requiring additional code to be written in the client or server.

[0015] Therefore, deployment flexibility is increased to meet dynamic system requirements across different customers. In one example, one approach allows software components to be deployed in the same or different ECU / OS / super-supervisor OS or over the internet, while exclusively relying on or exclusively providing the DCIF software interface of interest. The DCIF software bus can manage one or more of the following: security, access control, permissions, service discovery, N transport protocols, encryption, and interface version compatibility.

[0016] In one example, DCIF implementation may include the use of standardized service contracts. For instance, the system may enable the use of domain-specific languages ​​(DSLs), such as New Interface Definition Language (FIDL) for defining and transforming software interfaces, and Component Description Language (CDL) for describing the interfaces and behavior of software components. In another example, DCIF may implement service discoverability. For example, DCIF may support both dynamic service discovery and static configuration. A DCIF daemon (e.g., a long-running background process of DCIF configured to respond to requests) may build a catalog of services available on different protocols and configure policies and priorities for services in some or per-node scenarios (e.g., between different nodes in a communication control system).

[0017] In yet another example, DCIF implementations may include service abstractions that hide service deployment details behind standardized service contracts. Individual services can be provided on different communication buses. Furthermore, service composability can be implemented, allowing multi-process applications to be deployed on different ECUs. Each ECU can be a controller with a processor and memory storing instructions, including communication protocols for communication along the network's vertical axis.

[0018] DCIF can receive data via different communication protocols and distribute it to applications through a consistent application programming port (API), while hiding the complexity of doing so. Additionally, DCIF supports protocol converters to transform data from one protocol to another. Therefore, DCIF can be deployed in a variety of communication control systems, including but not limited to digital cockpits (configured with infotainment and clustering), advanced driver assistance systems (ADAS), telematics units (TCUs), rear-seat entertainment units, front-seat passenger display modules, and cloud platform implementations.

[0019] In some examples, DCIF can be implemented in connected vehicles. This approach can also complement or replace other software bus technologies such as dbus, which can be a single transport protocol oriented towards or specifically configured for a single system. Figure 1As shown, DCIF enables various vehicle systems to be communicatively coupled through a single connectivity module in which DCIF can be deployed.

[0020] Now go to Figure 1 An example of a vehicle system 100 for services and clients is shown. System 100 may include an external wireless network 102, which includes a cloud platform 104 and a vehicle-to-the-world (V2X) communication system 106, and an in-vehicle wireless network 108, which may include a hotspot network 110 and a Bring Your Own Device (BYOD) system 112. System 100 may also include an in-vehicle wired network 114. The in-vehicle wired network 114 may include a diagnostic system 116, an input / output (I / O) controller 118 configured to control vehicle sensors 120, and a computing node 122 for controlling devices such as cameras 124 and radar 126.

[0021] At least a portion of the services and clients of vehicle system 100 may rely on non-hardware-based connections, such as external wireless network 102 and in-vehicle wireless network 108, while other portions may rely on hardware, such as in-vehicle wired network 114. For example, data from sensor 120 may be processed in a regional controller, cloud platform 104 may support infotainment services, V2X communication system 106 may require specific infrastructure, and camera 124 and radar 126 may require dedicated ECUs. Therefore, there is a need for a technology that provides simultaneous communication between various services and clients, and that also enables seamless integration of handheld devices, for example, linked via BYOD system 112.

[0022] For example, such as Figure 1 As shown, the service and client can be communicatively coupled via connection module 128. Connection module 128 may be equipped with network security devices 130, such as a firewall. At least a portion of the vehicular wired network 114 can be selectively coupled to connection module 128 via switch 132. By configuring connection module 128 as DCIF, multi-platform middleware is provided, which allows cross-platform communication (e.g., ...) between different types of networks. Figure 1 The network depicted in the diagram communicates with the device. Furthermore, DCIF is a single-bus system, thus minimizing the complexity of the connection module 128.

[0023] DCIF can be included in a network of communication buses, such as Figure 2The first example of implementing DCIF within a network 200 of a communication bus is shown. In one example, network 200 may include components installed in a vehicle's communication control system, at a server, at other computing systems, etc. Communication between software modules of network 200 is achieved via DCIF. Network 200 includes an HTTP / Swagger bus 202, a Tesseract bus 204 (e.g., for WebSockets), a Distributed Service Interface (DSI) bus 206 (e.g., for Unix sockets), and a SoME / IP bus 208 (which may use Transmission Control Protocol / Internet Protocol (TCP / IP) or User Datagram Protocol (UDP)). A first ECU 210 and a second ECU 212 are included in network 200, in which the Tesseract bus 204 and DSI bus 206 are implemented. The first ECU 210 and the second ECU 212 may be communicatively coupled via the SoME / IP bus 208.

[0024] For example, the first ECU 210 may be implemented in a vehicle communication control system and may include an instrument cluster 216 (hereinafter referred to as cluster 216), which may be a node of a digital cockpit. Cluster 216 may support various applications, middleware, and databases. Cluster 216 may include a human-machine interface (HMI) 218 ​​communicatively coupled to the DSI bus 206. The DSI bus 206 is also communicatively coupled to a middleware (MW) service 220, which provides applications with services and capabilities beyond those provided by the operating system and the DCIF daemon 222.

[0025] DCIF daemon 222 can build a service catalog available on different protocols. Additionally, DCIF daemon 222 can configure policies and priorities for cluster-specific services 216. MW service 220 can communicatively couple to SoME / IP bus 208. DCIF daemon 222 can also be communicatively coupled to SoME / IP bus 208 directly and indirectly via SoME / IP Service Data (SD) daemon 224. SoME / IP Service Data (SD) daemon 224 can specify the SoME / IP format, message sequence, and semantics.

[0026] The first ECU 210 may also be equipped with an in-vehicle infotainment (IVI) subsystem 226. The IVI subsystem 226 can be configured to control various hardware and software in the vehicle that provide audio and video entertainment, including a car navigation system, video player, USB and Bluetooth connectivity, steering wheel audio controls, and hands-free voice control. The IVI subsystem 226 may include multiple network applications 228 communicatively coupled to the HTTPS / Swagger bus 202 and the Tesseract bus 204. Similar to the DSI bus 206, the Tesseract bus 204 communicatively coupled to the MW service 230 and the DCIF daemon 232. The MW service 230 communicatively coupled to the HTTPS / Swagger bus 202 and the SoME / IP bus 208. The DCIF daemon 222 may also be communicatively coupled to the SoME / IP bus 208 directly and indirectly via the SoME / IP Service Data (SD) daemon 234. The HTTPS / Swagger bus 202 may also be communicatively coupled to the cloud platform 236.

[0027] The second ECU 212 can be a node of network 200. For example, the second ECU 212 can be a connection point capable of receiving, creating, storing, or sending data, for example, via SOME / IP bus 208. The second ECU 212 may be equipped with MW service 238 and DCIF daemon 240, which can each be directly communicatively coupled to SOME / IP bus 208. DCIF daemon 240 may also be indirectly coupled to SOME / IP via SOME / IP SD daemon 242.

[0028] By incorporating DCIF into the network, for example by installing a DCIF daemon in each of the first ECU 210 and the second ECU 212, applications from different ECUs in the network 200 can be processed. DCIF allows additional ECUs to be added to the network 200 and coupled to communicate with each other without changing or adding new code. It also efficiently enables the use of various software modules within the ECUs.

[0029] A second example of implementing DCIF within an Ethernet-based control network 300 for vehicles. Figure 3As shown in the diagram. Integrating Ethernet into the control network 300 may be desirable to increase connectivity and may eventually replace the use of Controller Area Network (CAN). However, at least initially, a combination of Ethernet and CAN may be included in the control network 300. For example, the control network includes entities such as a first vehicle controller (VC) 302, a first domain 304, a second VC 306, a domain controller 308, and a cloud platform 314. Entities may receive and transmit signals via CAN 310 and Ethernet 312, and each entity may include a first service 316 that uses DCIF to convert the received and transmitted signals, enabling the entities to communicate with each other.

[0030] In addition to the first service 316, each entity may also be equipped with various tools, applications, and transport protocols. For example, the first VC 302 may include a service-oriented architecture (SOA) adapter 318 for signal-to-service (S2S), a CAN router 320, a CAN interface 322, a service discovery 324, and an Ethernet (TCP / IP) interface 326. The SOA adapter 318 may also include signal extraction and S2S conversion.

[0031] For example, S2S can provide tools or infrastructure to enable the transmission of signals via traditional protocols such as CAN 310, Local Area Network (LIN), FlexRay, etc., to function as services on SOA adapter 318. Thus, use case connectivity signals can be built between, for example, network edge and cloud platform.

[0032] The first domain 304 may include a second service 328 and up to N additional services 330, an SOA gateway 332, an Ethernet (TCP / ICP / UDP) virtual interface 334, and an Ethernet (TCP / ICP / UDP) external interface 336. The SOA gateway 332 may be a set of service infrastructure hosting tools, such as protocol translation, service interface translation, policy and access management, unified service discovery, unified service registration, protocols such as SoME / IP, Data Distribution Service (DDS), gRPC, and MQTT, and security protocols such as HTTPS, WSS, TLS, and DTLS.

[0033] The second VC 306 may include S2S 338 and service discovery 340. Domain controller 308 may include cluster 342, IVI 344, and virtual Ethernet 346. Each of cluster 342 and IVI 344 may be equipped with service discovery 340, and IVI 344 may also include SOA gateway 332.

[0034] Communication links can be established between common components of entities. For example, the first domain 304 can communicate with the domain controller 308 via the SOA gateway 332, and the first VC 302 can communicate with the second VC 306 via the SOA adapter 318 and the S2S 338.

[0035] By using Figure 3 The tools, applications, and protocols shown (such as S2S), via CAN (and other legacy protocols including Local Area Network (LIN) and FlexRay), can be represented as services on the DCIF, e.g., first service 316. The DCIF enables capability paths indicated by dashed lines 348, which can include CAN signal-to-service conversion, runtime service discovery, communication via Ethernet, service interface and protocol conversion via the exposed interface of cloud platform 314, and communication with cloud services via secure and authenticated channels. Implementing the DCIF in the vehicle communication control system enables interoperability of different transport protocols in network 300, allowing for the construction of complex end-to-end use cases. Different Ethernet-based communication protocols on the vehicle can be used and managed via a single software bus. Even as communication protocols evolve with new vehicle models or model variants, communication between different services and clients of the network is maintained by the DCIF.

[0036] DCIF provides users (e.g., developers) with model-driven development, enabling a higher level of abstraction in software buses than traditional single-transmission-oriented buses. Therefore, users can focus more on other aspects of the model, such as business logic, rather than on implementing and managing communication between software modules that control the network. An example of DCIF 400 is... Figure 4 The diagram illustrates the various components included in DCIF, which allow DCIF to manage complex tasks based on a single service contract.

[0037] For example, DCIF 400 may include multiple components such as tools 402, service interfaces 404, protocols 406, and inter-domain communication 408. Tools 402 may include modeling using a DSL, a generator for generating code, a validator, an editor, a graphical viewer, etc. Service interfaces 404 may include Service Application Programming Interfaces (SAPI) and Common Application Programming Interfaces (CAPI). Protocols 406 may include the Tesseract protocol, Distributed Service Interface (DSI), SoME / IP protocol, and software architecture styles such as Representational State Transfer (REST). Inter-domain communication 408 may include communication between the Android platform and the QNX operating system, between the Linux operating system and the QNX operating system, between the Linux operating system and the Integrity operating system, between the Android platform and the Integrity operating system, and between the Automotive Open Systems Architecture (Autosar) and the Portable Operating System Interface (POSIX) operating system. It should be noted that... Figure 4 The framework shown for DCIF is a non-limiting example, and other examples may be included. Figure 4 Additional elements not shown.

[0038] Therefore, model-driven development is aided by powerful code generators, service interfaces that hide protocols while allowing high-level abstractions, protocols (such as automotive middleware protocols that can be used to control messages), and protocol converters and bridges for communication between different operating platforms and systems.

[0039] exist Figure 5 The document describes a method 500 for enabling communication between different networks in a vehicle system. Method 500 can be used in vehicle systems (such as...) Figure 1 The DCIF is executed in a vehicle system 100, which is configured with various networks and each network communicates via a different transmission protocol. DCIF can be implemented in the vehicle system's connectivity module (e.g., Figure 1 Implemented at the connection module 128), the DCIF is configured with Figure 4 The components shown. It should be understood that, Figure 5 The order of operations shown is not restrictive, and the order of operations can vary. In other words, the operations can occur sequentially, simultaneously, partially or entirely, or in different orders.

[0040] At 502, the method includes identifying and mapping different transport protocols of the network. For example, identifying the network may include confirming whether the network is wireless or wired. Mapping the network may include determining the specific type of transport protocol corresponding to each network.

[0041] In the 504 error, the method includes adapting each type of transport protocol to a common API. For example, the common API could be described by a common DSL, making it possible to define and discover each service provided by the network. A protocol converter can be used to convert transport protocols. A generic API can abstract multiple protocols, which increases the flexibility of DCIF data consumption regardless of the transport type, thus avoiding the need for code changes.

[0042] At 506, the method includes constructing a service catalog based on the identified network and transport protocols. At 508, a standardized service contract can be provided, which hides the deployment details of the services. At 510, multiple applications can be processed simultaneously, allowing the deployment of different software modules regardless of host configuration without rewriting existing code or adding new code.

[0043] In this way, DCIF allows for highly abstract system deployment across networks. Networks can include multiple transport protocols, and communication between different transport protocols can be achieved through DCIF without writing or adding new code to the client or server. The DCIF implementation also reduces the need for new code when adding clients to the network. Protocols can be hidden behind standardized service interfaces. Therefore, multilingual distributed applications and services can be built securely and efficiently.

[0044] The technical advantage of applying DCIF to communication networks is that it enables communication between different types of operating systems, ECUs, and processes based on existing code.

[0045] The implementation scheme has been described for illustrative and descriptive purposes. Suitable modifications and changes to the implementation scheme can be obtained from the above description or through practical methods. For example, unless otherwise indicated, modifications and changes can be made through methods such as... Figure 1 One or more of the described methods may be performed using suitable means and / or combinations of means as shown in the vehicle system 100. The methods may be performed by executing stored instructions in combination with one or more logical means (e.g., a processor) and one or more additional hardware elements such as storage devices, memories, hardware network interfaces / antennas, switches, actuators, clock circuits, etc. The described methods and associated actions may also be performed in various orders other than those described in this application, in parallel, and / or simultaneously. The described systems are exemplary in nature and may include additional and / or omitted elements. The subject matter of this disclosure includes all novel and non-obvious combinations and sub-combinations of the various systems and configurations disclosed, as well as other features, functions, and / or properties.

[0046] This disclosure also provides support for an apparatus for a communication control system, the apparatus including a Distributed Component Interconnection Framework (DCIF), the DCIF being configured to implement communication between different software modules of a communication network based on existing code. In a first example of the system, the DCIF uses a Domain-Specific Language (DSL) to define interfaces and components deployed on different nodes and / or domains. In a second example of the system, optionally including the first example, the DCIF is configured to support one or more of dynamic service discovery and static configuration. In a third example of the system, optionally including one or both of the first and second examples, the DCIF includes a DCIF daemon configured to build a service catalog available through different protocols and manage the policies and priorities of services in each node of the communication control system. In a fourth example of the system, optionally including one or more of the first to third examples, or each of them, the DCIF is configured to manage one or more of the following: security, access control, privileges, service discovery, N transport protocols, encryption, and interface version compatibility. In a fifth example of the system, which optionally includes one or more of the first to fourth examples, the DCIF is configured to hide the deployment details of the services provided by the DCIF behind a standardized service contract. In a sixth example of the system, which optionally includes one or more of the first to fifth examples, the DCIF is implemented in the vehicle's communication control system.

[0047] This disclosure also provides support for a method for a communication control system, the method comprising: operating a Distributed Component Interconnection Framework (DCIF) to identify and map the networks of the communication control system; converting the protocols of the networks into common protocols via the DCIF to enable communication between the networks; constructing a service catalog and providing standardized service contracts based on services provided by the networks; and simultaneously processing multiple applications configured for different types of hosts. In a first example of the method, operating the DCIF to identify and map the networks includes determining the configuration of each in the networks and the transport protocol type corresponding to each in the networks. In a second example of the method, optionally including the first example, converting the protocols of the networks includes using a domain-specific language to define interfaces and components on different nodes and / or domains. In a third example of the method, optionally including one or both of the first and second examples, constructing the service catalog includes providing service abstraction by hiding the deployment details of the service catalog behind standardized service contracts.

[0048] This disclosure also supports a communication control system comprising: one or more transport protocols; and a Distributed Component Interconnection Framework (DCIF) implemented in a connectivity module of the communication control system, the DCIF being configured to allow communication between the one or more transport protocols. In a first example of the system, the DCIF is configured with multiple tools for implementing model-driven development, and wherein said multiple tools include a code generator. In a second example of the system optionally including the first example, the multiple tools further include one or more of a modeler, validator, editor, and graphical viewer in a domain-specific language. In a third example of the system optionally including one or both of the first and second examples, the DCIF is configured with multiple service interfaces. In a fourth example of the system optionally including one or more, or each, of the first to third examples, the multiple service interfaces include one or more of a Service Application Programming Interface (SAPI) and a Common Application Programming Interface (CAPI). In a fifth example of the system optionally including one or more, or each, of the first to fourth examples, the DCIF is configured with multiple communication protocols, and wherein said multiple communication protocols are middleware protocols for controlling messages. In a sixth example of a system that optionally includes one or more of the first through fifth examples, the plurality of communication protocols includes one or more of Tesseract, Distributed Service Interface (DSI), Internet Protocol-based Scalable Service Middleware (SoME / IP), and Representational State Transition (REST). In a seventh example of a system that optionally includes one or more of the first through sixth examples, the DCIF is configured for inter-domain communication, and the inter-domain communication includes protocol converters and bridges between operating systems. In an eighth example of a system that optionally includes one or more of the first through seventh examples, the inter-domain communication enables communication between one or more of the following: Android platform and QNX operating system, Linux operating system and QNX operating system, Linux operating system and Integrity operating system, Android platform and Integrity operating system, and Automotive Open System Architecture and Portable Operating System Interface operating system.

[0049] As used in this application, elements or steps described in the singular followed by the words "an" or "a" should be understood as not excluding multiple said elements or steps, unless such exclusion is stated. Furthermore, references to "an embodiment" or "an example" in this disclosure are not intended to be construed as excluding the existence of additional embodiments that also incorporate the described features. The terms "first," "second," and "third," etc., are used merely as designations and are not intended to impose numerical requirements or a particular order on their objects. The appended claims specifically point to subject matter deemed novel and non-obvious from the foregoing disclosure.

Claims

1. A method for a communication control system for a vehicle, comprising: The Distributed Component Interconnection Framework (DCIF) is used to implement communication between multiple different software modules of a communication network based on existing code. A service catalog available through different protocols of the multiple different software modules is constructed by the DCIF daemon. Standardized service contracts are provided based on a service catalog available through different protocols of the multiple different software modules, and The DCIF uses a domain-specific language DSL to define the interfaces and components deployed on different nodes and / or domains. The communication network includes the vehicle's Internet Protocol-based, scalable service-oriented middleware SoME / IP bus; and Each of the plurality of different software modules is implemented in the vehicle’s electronic control unit (ECU), which is coupled to the SoME / IP bus.

2. The method of claim 1, wherein the DSL is selected from a set including a New Interface Definition Language (FIDL) and a Component Description Language (CDL).

3. The method of claim 1, wherein the DCIF is configured to support one or more of dynamic service discovery and static configuration.

4. The method of claim 1, further comprising the strategy and priority of the services available through different protocols constructed by the DCIF daemon and managed by the DCIF daemon in each node of the communication control system.

5. The method of claim 4, further comprising the DCIF managing one or more of the following: security, access control, permissions, service discovery, N transport protocols, encryption, and interface version compatibility.

6. The method of claim 1, further comprising providing a service abstraction by the DCIF hiding the deployment details of the service catalog behind standardized service contracts; and Multiple applications can be processed simultaneously, and these applications are configured for different types of hosts.

7. A method for a communication control system, the method comprising: The Distributed Component Interconnection Framework (DCIF) is used to identify and map multiple networks of the communication control system, and to determine the configuration of each of the multiple networks and the multiple transport protocol types corresponding to the multiple networks. The DCIF converts the protocols of the multiple networks into a common protocol to enable communication between the multiple networks via SoME / IP, a middleware for scalable services based on Internet Protocol. Because the multiple DCIF daemons corresponding to the multiple transport protocol types construct a service catalog available through the multiple networks based on the services provided by the multiple networks and provide standardized service contracts, and provide service abstraction by hiding the deployment details of the service catalog behind the standardized service contracts; as well as Simultaneously process multiple applications, which are configured for different types of hosts. Each of the plurality of transport protocol types has a bus coupled to the plurality of DCIF daemons; Each of the plurality of DCIF daemons is directly coupled to the bus of the common protocol; and Each of the plurality of DCIF daemons is indirectly coupled to the bus of the common protocol through one of the plurality of service data SD daemons corresponding to the bus of the common protocol.

8. The method of claim 7, wherein converting the protocols of the plurality of networks includes using a domain-specific language to define interfaces and components on different nodes and / or domains.

9. A method for a communication control system, comprising: The Distributed Component Interconnect Framework (DCIF) operates in the connection module of the communication control system to allow multiple transmission protocols to communicate through multiple communication buses in a communication bus network, the multiple communication buses corresponding to the multiple transmission protocols; Construct a service catalog available for different protocols through the multiple transport protocols; and Standardized service contracts are provided based on the service catalog provided by the multiple communication buses. The first electronic control unit (ECU) implements the first communication bus, the first DCIF daemon process, and the first SoME / IP service data daemon process, which is a middleware based on Internet protocol and oriented towards scalable services, among the multiple communication buses. The first communication bus is communicatively coupled to the first DCIF daemon process; The first DCIF daemon is directly and indirectly coupled to the SoME / IP bus in the network through the SoME / IP service data daemon of the network. The second ECU implements the second communication bus, the second DCIF daemon process, and the second SoME / IP service data daemon process among the multiple communication buses; The second communication bus is grounded and coupled to the second DCIF daemon; and The second DCIF daemon is directly or indirectly coupled to the SoME / IP bus in the network through the SoME / IP service data daemon of the network.

10. The method of claim 9, wherein the DCIF is configured with a plurality of tools to implement model-driven development, and wherein the plurality of tools includes a code generator.

11. The method of claim 10, wherein the plurality of tools further includes one or more of a modeler, validator, editor, and graphical viewer in a domain-specific language.

12. The method of claim 9, wherein the DCIF is configured with multiple service interfaces.

13. The method of claim 12, wherein the plurality of service interfaces includes one or more of a Service Application Programming Interface (SAPI) and a Public Application Programming Interface (CAPI).

14. The method of claim 9, wherein the DCIF is configured with a plurality of communication protocols, and wherein the plurality of communication protocols are middleware protocols for control messages.

15. The method of claim 14, wherein the plurality of communication protocols includes one or more of Tesseract, Distributed Service Interface (DSI), and Representational State Transition (REST).

16. The method of claim 9, wherein the DCIF is configured for inter-domain communication, and wherein the inter-domain communication includes a protocol converter and bridge between operating systems.

17. The method of claim 16, wherein the inter-domain communication enables communication between one or more of the following: Android platform and QNX operating system, Linux operating system and QNX operating system, Linux operating system and Integrity operating system, Android platform and Integrity operating system, automotive open system architecture and portable operating system interface operating system.

Images