System for connecting a large number of providers and a large number of recipients

Abstract

A system (10) for connecting a large number of providers (12) and a large number of receivers (14), wherein the system (10) comprises: a unified vehicle service framework (16) configured to communicate with the multitude of providers (12) and the multitude of receivers (14), wherein the unified vehicle service framework (16) includes a quality-of-service filter (22) and a broker module (30); where the multitude of providers (12) and the multitude of recipients (14) are accommodated independently of each other; a first cloud unit (50) with at least one of the multitude of providers (12) and the multitude of recipients (14); several vehicles (56), including a first vehicle (58) and a second vehicle (60), wherein the first vehicle (58) and the second vehicle (60) each have a different one of the plurality of providers (12) and / or the plurality of receivers (14); wherein the unified vehicle service framework (16) comprises a processor (P) and a tangible non-volatile memory (M) on which instructions are recorded, wherein the execution of the instructions by the processor (P) causes the unified vehicle service framework (16) to: Maintaining a database containing the multitude of providers (12), the multitude of recipients (14) and the respective services originating from the multitude of providers (12); Receipt of a subscription request from a requesting member of the multitude of recipients (14) for the respective services; Determine whether the subscription request is granted based on a Quality of Service score assigned by the Quality of Service filter (22), and inform the requesting member of the multitude of recipients; and when the subscription application is submitted, the broker module (30) directs the relevant services.

Description

[0001] This disclosure relates generally to a method and system for connecting a multitude of providers and receivers to a unified framework for vehicle services. The ever-increasing complexity of devices, including but not limited to vehicles, has led to a rise in the amount of information provided by various entities and consumed by various applications. The information flow paradigm is generally implemented separately for communication between vehicles and communication within the vehicle. Consolidating the information flow is challenging when information providers and receivers are dispersed across different systems and subsystems.

[0002] US 8 514 825 B1 describes a procedure encompassing connecting to a vehicular access network (VAN) that includes cooperative communication between multiple on-board units (OBUs) in the respective vehicles, scanning the VAN to detect the coverage of at least one infrastructure access point (IAP) operating on a control channel in a multi-cell radio access tree (RAT), receiving channel allocation information from the IAP that includes a request for a mobile cell gateway (MCG) at a nominal location in the RAT, and sending a candidate message to the at least one IAP to act as the MCG.

[0003] US 2018 / 0 287 891 A1 concerns network and / or application resources that can be dynamically instantiated based on Quality of Service (QoS) data.

[0004] It can be considered a task to provide an alternative system with which a large number of providers and a large number of receivers can be connected, thereby unifying and improving both in-vehicle and inter-vehicle communication. This task is accomplished by the subject matter of claim 1.

[0005] This document discloses a method and system for connecting a multitude of providers and a multitude of recipients to a unified vehicle service framework. The system according to the invention comprises a unified vehicle service framework, a quality-of-service filter, and a broker module. The multitude of providers and the multitude of recipients are located independently of one another. A first cloud unit has at least one of the multitude of providers and at least one of the multitude of recipients (e.g., a provider or a recipient). A multitude of vehicles comprises a first vehicle and a second vehicle. The first vehicle and the second vehicle each have at least one further vehicle from the multitude of providers and at least one further vehicle from the multitude of recipients.

[0006] The unified vehicle service framework comprises a processor and tangible, non-volatile memory on which instructions are recorded. The processor's execution of these instructions causes the unified vehicle service framework to maintain a database of the multitude of providers, the multitude of receivers, and the respective services provided by the multitude of providers. The unified vehicle service framework is configured to receive a subscription request from a requesting member of the multitude of receivers for the respective services. The unified vehicle service framework is configured to determine whether the subscription request will be granted based on a Quality of Service score assigned by the Quality of Service filter and informs the requesting member of the multitude of receivers.When the subscription application is submitted, the relevant services are routed through the broker module.

[0007] According to one embodiment, the Quality of Service score can be a weighted sum of a priority score, a persistence score, an interrelationship score, and an authorization score. The priority score is assigned to the subscription request based on a relative importance value. The persistence score is assigned to the subscription request based on the average time the respective services spent in the broker module before consumption. The interrelationship score is assigned to the subscription request due to its relationship to other respective services. The authorization score is assigned to the subscription request based on at least one security factor and one trust factor assigned to the requesting member of the plurality of recipients.

[0008] According to one embodiment, the unified vehicle service framework includes a syntax module configured such that the respective services are classified as at least one of a messaging service and one call service. The messaging service is defined as an informational message that does not require any action from the multitude of recipients. The call service is defined as automatically triggering a predefined response from the multitude of recipients.

[0009] In one embodiment, the broker module comprises at least one leaf unit configured to communicate directly with one or more of the plurality of providers and the plurality of receivers, and a root server hosted by the first cloud unit. The broker module also comprises at least one branch unit configured to act as an intermediary between the root server and the leaf unit to route the respective services. The respective services are registered with the root server. In one embodiment, the at least one leaf unit and the at least one branch unit are hosted by the first cloud unit. In another embodiment, the at least one leaf unit is hosted by the first vehicle.

[0010] According to one embodiment, the branch unit is configured to execute several control plane modules, including a node child registration module, a node parent registration module, and a broker module maintenance module. The node child registration module and the node parent registration module each comprise a data structure that registers one or more nodes downstream and upstream, respectively, of the at least one branch unit in the broker module. The broker module maintenance module is configured to detect entries for new units and non-operating units in the broker module.

[0011] According to one embodiment, the broker unit is configured to execute multiple data layer modules. The multi-data layer modules may include a physical topology maintenance module, configured to maintain one or more centralized modules that record the entry of a new node or the exit of an existing node. The multi-data layer modules also include a traffic shaping module configured to artificially delay traffic so that the respective services with a higher Quality of Service (QoS) score can be transmitted relatively sooner.According to one embodiment, the multiple data layer modules include a virtual provider module configured to aggregate the respective services provided by the multitude of providers into a single virtual service if the respective services have the same Quality of Service (QoS) score. The traffic shaping module is configured to treat the individual virtual service as a single data set. Fig. Figure 1 is a schematic representation of a system for connecting a large number of providers and a large number of receivers via a unified vehicle service framework, wherein the unified vehicle service framework includes a broker module; Fig. Figure 2 is a schematic flowchart for a procedure that uses the unified vehicle service framework of Fig. 1 can be executed; Fig. Figure 3 is a schematic first example implementation of the system from Fig. 1 with a central broker architecture for the broker module; Fig. Figure 4 is a schematic second example implementation of the system from Fig. 1, with a distributed broker architecture for the broker module; Fig. Figure 5 is a schematic representation of an example broker module used within the framework of the unified vehicle service by Fig. 1 is used, with the broker module having a branch; and Fig. 6 is a schematic representation of the operations performed by the branch of Fig. 5 will be carried out.

[0012] Referring to the figures in which the same reference symbols refer to the same components, it is stated in Fig. 1 A system 10 for connecting a large number of providers 12 with a large number of recipients 14 through a uniform vehicle service framework 16 is shown schematically. (Related to) Fig. 1. The multitude of providers 12 can include a first provider 12A, a second provider 12B, a third provider 12C, and a fourth provider 12D, with reference to Fig. The plurality of receivers 14 can include a first receiver 14A, a second receiver 14B, a third receiver 14C, and a fourth receiver 14D. The number of providers 12 and the plurality of receivers 14 can be varied depending on the application. The system 10 unifies communication between vehicles and communication within the vehicle, offering lower latency due to a common protocol, thus avoiding translation between in-vehicle and in-vehicle communication systems.

[0013] The multitude of providers 12 and the multitude of receivers 14 can be physically located or hosted independently of each other. In other words, the physical location of one of the multitude of providers 12 and the multitude of receivers 14 is not affected by or independent of the physical location of the others.

[0014] The multitude of providers 12 are the source of the information, referred to here as the respective services, which are used by the receiver 14. The multitude of providers 12 can provide synthesized data, such as a sensor output. The multitude of receivers 14 can be intelligent software modules or mobile applications ("apps"). Examples of the corresponding services include, among others, Global Positioning System (GPS) services, fault management services, weather information services, traffic information services, radar sensor data, and optical sensor data from a specific location, as well as calibration data for fuel consumption using various algorithms in a vehicle.

[0015] As in Fig. As shown in Figure 1, the unified vehicle service framework 16 comprises a processor P and tangible, non-volatile memory M, which is configured to store data structures, such as a database 18. The unified vehicle service framework 16 is configured to manage the database 18 of the multitude of providers 12, the multitude of recipients 14, and their respective services. Memory M can store multiple control-executable instruction sets, and the processor P can execute the multiple control-executable instruction sets stored in memory M.

[0016] With reference to Fig. 1. The multiple control executable instruction sets comprise a procedure 20 and a quality-of-service filter 22, which are in Fig. 2 will be described in detail.

[0017] The unified automotive service framework 16 contains, according to Fig. 1. A broker module 30 for forwarding the respective services from the multitude of providers 12 to the multitude of recipients 14. The broker module 30 can be set up in different ways. Fig. Figure 3 shows an example implementation of System 10 with a centralized broker architecture. Fig. Figure 4 shows another example of a System 110 with a distributed broker architecture. Systems 10 and 110 include, according to... Fig. 3-4 A first cloud unit 50 with at least one of the plurality of providers 12 and the plurality of receivers 14. In other words, the first cloud unit 50 is the host for at least one member, which can be a provider or a receiver. In the example shown, the first cloud unit 50 is the first provider 12A and the first receiver 14A. A second cloud unit 52 includes at least one more from the plurality of providers 12 and the plurality of receivers 14. In the example shown, the second cloud unit 52 is the host for the second provider 12B. For example, the first cloud unit 50 can be maintained / owned by a vehicle manufacturer, and the second cloud unit 52 can be maintained / owned by a supplier of a component used by the vehicle manufacturer.The first cloud unit 50 and the second cloud unit 52 can contain one or more remote servers (not shown) hosted on the internet for storing, managing, and processing data. The first cloud unit 50 and the second cloud unit 52 can be connected to a central server 54.

[0018] Systems 10 and 110 comprise, according to Fig. 3-4 a plurality of vehicles 56, such as first vehicle 58 and second vehicle 60. The first vehicle 58 and the second vehicle 60 each have at least one further of the plurality of providers 12 and the plurality of receivers 14. In the example shown, the first vehicle 58 includes the third provider 12C, the second receiver 14B, the third receiver 14C, and the fourth receiver 14D. In the example shown, the second vehicle 60 includes a fourth provider 12D, a fifth provider 12E, a sixth receiver 14F, and a seventh receiver 14G. For example, the fourth provider 12D can be a mobile application running in the control unit (not shown) of the second vehicle 60 and specifically programmed to retrieve information stored on the vehicle bus, including information transmitted to the vehicle bus by a radar sensor.

[0019] In the first embodiment, which is described in Fig. As shown in Figure 3, the broker module 30 is hosted exclusively by the first cloud unit 50. In the second embodiment, which is shown in Figure 3, the broker module 30 is hosted exclusively by the first cloud unit 50. Fig. As shown in Figure 4, the broker module 30 is divided into several sub-broker modules, which are housed in multiple locations. In the [section / document] Fig. In the example shown, a first sub-broker 130A is located in the first cloud unit 50, a second sub-broker 130B in the first vehicle 58, and a third sub-broker 130C in the second vehicle 60. The broker module 30, the first sub-broker 130A, the second sub-broker 130B, and the third sub-broker 130C can each contain a corresponding memory for storing instructions and a corresponding processor for executing the instructions.

[0020] The multitude of vehicles 56 can be mobile platforms, such as passenger cars, sport utility vehicles, light commercial vehicles, heavy-duty vehicles, ATVs, minivans, buses, transit vehicles, bicycles, robots, agricultural equipment, sporting equipment, boats, aircraft, trains, or other transport devices. The majority of vehicles 56 can comprise transport devices in many different forms and include multiple and / or alternative components and facilities.

[0021] Regarding Fig. Figure 2 shows a flowchart of Procedure 20. Procedure 20 need not be applied in the order shown here, and some blocks may be omitted. The Unified Vehicle Service Framework 16 is specifically programmed to execute the blocks of Procedure 20. For each block 24, the Unified Vehicle Service Framework 16 is configured to receive a subscription request from a requesting member (e.g., First Recipient 14A) of the plurality of Recipients 14 for the respective services provided by another of the plurality of Providers 12. The term "subscription" refers to consent to the delivery of data for a specific period. For example, the Unified Vehicle Service Framework 16 may make an initial request R1a request is received from the first recipient 14A and a second request R2 from the second recipient 14B. Alternatively, the majority of providers 12 can be configured to send corresponding subscription offers to the multitude of recipients 14, such as the first offer O1 (see Fig. 1) and the second offer O2 from the second provider 12B or the third provider 12C. The subscription applications can be forwarded simultaneously to several of the numerous recipients 14.

[0022] For each block 26, the unified vehicle service framework 16 is configured to determine whether the subscription application is granted based on the Quality of Service filter 22. The Quality of Service filter 22 is configured to assign an overall score as a weighted sum of several scores. The weighting factors (w iThe scores can be selected depending on the application. The majority of the scores can include a priority score, a persistence score, an interrelationship score, and an entitlement score. The subscription request can be approved if the total score exceeds a threshold and / or if each of the multiple scores exceeds its respective individual thresholds. Total score = (w1 * priority score + w2 * persistence score + w3 * interrelation score + w4 * entitlement score).(w1 + w2 + w3 + w4) = 1

[0023] The priority score is assigned to the subscription request based on a relative importance value; for example, a service related to the braking function might receive a higher score than a service related to an infotainment system. The persistence score assigned to the subscription request is based on the average time the respective services remain in System 10 before being consumed. In other words, services that are consumed quickly receive a higher score.

[0024] An inter-relation score is assigned to the subscription request based on its relationship with other corresponding services, allowing messages to be grouped according to a relationship graph. The inter-relation score reflects whether the request concerns relevant services / data that share some commonality with other existing subscriptions in the system. The score is highest when the subscription request concerns a service already shared with another of the multiple recipients (14) located on the same hardware, e.g., both in the control unit of the first vehicle (58).

[0025] An authorization score is assigned to the subscription request based on at least one security factor and one trust factor, which is linked to the requesting member of the plurality of recipients. 14. In a non-restrictive example, a third-party app requests a service that provides high-resolution map data for autonomous vehicles. This data may be stored in the first cloud unit, in the majority of vehicles, or a combination of both. The third-party app in question is a navigation-only app and does not have the necessary authorization to access this data. The authorization score is therefore assigned the lowest possible score.

[0026] According to Block 28 of Fig. 2 the unified vehicle service framework 16 is set up so that the requesting member of the multitude of recipients 12 is informed whether the subscription request has been received, e.g., by the first notification N1 (see Fig. 1) and the second notification N2 is granted to the third recipient 14C or the fourth recipient 14D. When the subscription application is submitted, the respective services are retrieved from database 18 via the broker module 30, which is located in the Fig. The information is shown to be forwarded to the requesting member (e.g., first recipient 14A) of the multitude of recipients 14.

[0027] With reference to the Fig. The multitude of providers 12 and the multitude of receivers 14 can communicate with the unified vehicle service framework 16 either via one or a combination of a short-range network 34 and a long-range network 36. As in Fig. As shown in Figures 1 and 3-4, the short-range network 34 can be wireless or include physical components. The short-range network 34 can be a bus implemented in various ways, such as a serial communication bus in the form of a local area network. The network connection N can include, among other things, a Controller Area Network (CAN), a Controller Area Network with Flexible Data Rate (CAN-FD), Ethernet, Bluetooth, Wi-Fi, and other forms of data connection. The short-range network 34 can be a Bluetooth™ connection, which is defined as a short-range radio technology (or wireless technology) designed to simplify communication between Internet devices and between devices and the Internet. Bluetooth™ is an open wireless technology standard for transmitting data between fixed and mobile electronic devices over short distances, creating personal networks that operate in the 2.4 GHz band.Other connection types can also be used.

[0028] The long-range network 36 can be a Wireless Local Area Network (LAN) connecting multiple devices via a wireless distribution method, a Wireless Metropolitan Area Network (MAN) connecting multiple wireless LANs, or a Wireless Wide Area Network (WAN) covering large areas such as neighboring cities. Other connection types can also be used. Each of the multiple vehicles can contain a corresponding wireless transmitter-receiver (not shown), an adapter, or other circuitry available to the professionals to enable communication over the short-range network 34 and the long-range network 36.

[0029] Additionally, the unified vehicle service framework 16 can be used with reference to Fig. One executable instruction is included in conjunction with a syntax module 38. Syntax module 38 is configured to distinguish between a messaging service and a call service. The respective services can be characterized as a messaging service or a call service. The messaging service is defined as an informational message that does not require any action or response from the multitude of recipients 14 concerned. The call service is configured to automatically trigger a response from the majority of recipients 14 concerned. The call service is subject to greater restrictions than the messaging service. For example, a subscription request associated with a call service may require a higher threshold for the total score (assigned by the Quality-of-Service filter 22) to be granted by the unified vehicle service framework 16 than the messaging service.

[0030] Regarding Fig. 5 will now be an example topology for the broker module 30. Fig. 3 and the first sub-broker 130A, a second sub-broker 130B and the third sub-broker 130C from Fig. 4 shown.

[0031] As in Fig. As shown in Figure 5, the broker module 30 contains a root server 102, which is hosted by the first cloud unit 50. The respective services are registered on the root server 102. The routing of the respective services from the multitude of providers 12 to the root server 102 is shown with solid arrows. Subscription (or unsubscription) requests from the multitude of recipients 14 to the root server 102 and notifications from the root server 102 to the multitude of recipients 14 are shown with dashed arrows in two directions.

[0032] The broker module 30 contains at least one leaf unit, such as the first leaf 106, which is configured to communicate directly with one or more of the multitude of providers 12 and the multitude of receivers 14. The broker module 30 contains at least one branch unit, such as the first branch 104, which is configured to act as an intermediary between the root server 102 and the at least one leaf unit, such as the first leaf 106. In the Fig. In the example shown, Broker Module 30 includes a first branch 104, a second branch 108, a third branch 114, a fourth branch 116, a first leaf 106, a second leaf 110, a third leaf 112, a fourth leaf 118, and a fifth leaf 120. It should be understood that alternative configurations can be used.

[0033] In the centralized broker architecture, the first cloud unit 50 hosts the entire broker module 30, including the root server 102, branch offices, and leaves. In the distributed architecture, the first cloud unit 50 hosts the root server 102, but the branch offices and leaves can be located or hosted in the second cloud unit 52, the majority of the vehicles 56, and other locations. The centralized broker architecture may be suitable for applications with high requirements for reliability, data consistency, and transactional integrity. The distributed broker architecture may be suitable for applications with high requirements for high throughput, low latency, and system efficiency.

[0034] In Fig. In step 5, the configuration for broker module 30 is overlaid with the configuration for the first sub-broker 130A, the second sub-broker 130B, and the third sub-broker 130C. The first sub-broker 130A contains, according to... Fig. 5. A root server 102. The second sub-broker 130B comprises a first branch 104, a second branch 108, a first leaf 106, a second leaf 110, and a third leaf 112. The third sub-broker 130C comprises a third branch 114, a fourth branch 116, a fourth leaf 118, and a fifth leaf 120.

[0035] In the Fig. In the example shown in Figures 3-4, the first vehicle 58 comprises a third supplier 12C, the second receiver 14B, the third receiver 14C, and the fourth receiver 14D, also in Fig. Figure 5 illustrates this. The third provider, 12C, can be configured to route its respective services to the root server, 102, via the first branch, 104, and the first leaf, 106. The second receiver, 14B, and the third receiver, 14C, can be configured to send requests to the root server, 102, via the first branch, 104, the second branch, 108, and the second leaf, 110, and to receive notifications from it. The fourth receiver, 14D, can be configured to communicate with the root server, 102, via the third leaf, 112.

[0036] In the Fig. In the example shown in Figures 3-4, the second vehicle 60 includes a fourth provider 12D, a fifth provider 12E, a sixth receiver 14F, and a seventh receiver 14G, also in Fig. Figure 5 illustrates this. The fourth provider, 12D, and the fifth provider, 12E, can be configured so that their respective services are routed to the root server, 102, via the third branch, 114, the fourth branch, 116, and the fourth leaf, 118. The sixth receiver, 14F, and the seventh receiver, 14G, can be configured to send requests to the root server, 102, via the third branch, 114, and the fifth leaf, 120, and to receive notifications from it.

[0037] Fig. Figure 6 shows an example of the activity of at least one branch of Broker Module 30, such as the first branch 104 of Fig. 5. Branch Unit 104 is according to Fig. 6 is configured to allow multiple control plane modules 306 and multiple data plane modules 308 to run. The control plane modules 306 can contain a message QoS enforcement module 310 and a call QoS enforcement module 316, which are configured to implement and enforce the corresponding rules stored in the syntax module 38 (see Fig. ). The multiple control level modules 306 include a module for managing suppliers 318 and a module for managing recipients 320, each configured to manage requests, notices or messages to and from the multitude of suppliers 12 and the multitude of recipients 14 (see Fig. 1).

[0038] Regarding Fig. 6. Modules 306 for multiple control levels can contain a broker module 322, which is configured to record the entry of a new unit and the loss of a unit, e.g., a non-operating unit, in broker module 30. The modules of the multiple control level 306 can contain a node child registration module 324 and a node parent registration module 326, each with a corresponding data structure that registers one or more nodes after or before the branch unit 104, respectively.

[0039] As in Fig. As shown in Figure 6, the modules 308 with multiple data levels can contain a database manager 328, which is configured to manage a record of the respective routed services, such as the respective services routed to the first receiver 14A and the second receiver 14B. With regard to Fig. 6. The modules of the multiple data layer 308 can contain a traffic shaping module 332, which is configured to artificially delay traffic in order to transmit the respective services with a higher Quality of Service (QoS) score relatively earlier. The data layer modules 308 can contain a virtual provider module 330, which is configured to aggregate the respective services provided to the multiple receivers 14, such as the first receiver 14A and the second receiver 14B, via an in-network processing module 334. For example, if the respective services of the first provider 12A, the second provider 12B, and the third provider 12C have the same QoS score, they can be aggregated by the virtual provider module 330 into a virtual service and treated by the module 332 as a single data element for traffic shaping, thus simplifying data processing.As in . Fig. As shown in Figure 6, the modules 308 with multiple data levels can also include a module 336 for maintaining the physical topology, which is set up so that one or more central modules 338 record an entry of a new node or an exit of an existing node.

[0040] In summary, systems 10 and 110 unify both in-vehicle and cross-vehicle communication, providing transparency to mobile application developers regardless of where the apps are embedded or located. Additionally, a scalable and flexible solution is offered while maintaining proper functional isolation. The unified vehicle service framework 16 (and the execution of the procedure 20) improves the operation of multiple vehicles 56 by enabling rapid access to the respective services provided by a variety of vendors 12, which may be located in the same vehicle as the recipient, another vehicle, a first cloud unit 50, a second cloud unit 52, or elsewhere.

[0041] The Unified Vehicle Service Framework 16 includes at least one computer-readable medium (also referred to as a processor-readable medium), including a non-volatile (e.g., physical) medium, involved in providing data (e.g., instructions) that can be read by a computer (e.g., a computer's processor). Such a medium can take many forms, including, but not limited to, non-volatile and volatile media. Non-volatile media may include, for example, optical or magnetic disks and other permanent storage media. Volatile media may include, for example, dynamic random-access memory (DRAM), which may represent main memory. Such instructions may be transmitted via one or more transmission media, including coaxial cable, copper wire, and fiber optic cable, including the wires comprising a system bus coupled to a computer's processor.Some forms of computer-readable data storage media include, for example, a floppy disk, a flexible disk, a hard disk, a magnetic tape, other magnetic data storage media, a CD-ROM, a DVD, other optical data storage media, punched cards, paper tape, other physical data storage media with hole patterns, a RAM, a PROM, an EPROM, a FLASH EEPROM, other memory chips or cartridges, or other data storage media that a computer can read from.

[0042] Lookup tables, databases, data stores, or other data repositories described here can contain various mechanisms for storing, accessing, and retrieving different types of data, including a hierarchical database, a set of files in a file system, an application database in a proprietary format, a relational database management system (RDBMS), and so on. Each of these data stores can be contained within a computer device running a computer operating system such as one of those mentioned above and can be accessed over a network in one or more of the various ways. A file system can be accessed from a computer operating system and contain files in various formats. An RDBMS can use a structured query language (SQL), such as the PL / SQL language mentioned above, in addition to a language for creating, storing, editing, and executing stored procedures.

Claims

[1] A system (10) for connecting a large number of providers (12) and a large number of receivers (14), wherein the system (10) comprises: a unified vehicle service framework (16) configured to communicate with the multitude of providers (12) and the multitude of receivers (14), wherein the unified vehicle service framework (16) includes a quality-of-service filter (22) and a broker module (30); where the multitude of providers (12) and the multitude of recipients (14) are accommodated independently of each other; a first cloud unit (50) with at least one of the multitude of providers (12) and the multitude of recipients (14); several vehicles (56), including a first vehicle (58) and a second vehicle (60), wherein the first vehicle (58) and the second vehicle (60) each have a different one of the plurality of providers (12) and / or the plurality of receivers (14); wherein the unified vehicle service framework (16) comprises a processor (P) and a tangible non-volatile memory (M) on which instructions are recorded, wherein the execution of the instructions by the processor (P) causes the unified vehicle service framework (16) to: Maintaining a database containing the multitude of providers (12), the multitude of recipients (14) and the respective services originating from the multitude of providers (12); Receipt of a subscription request from a requesting member of the multitude of recipients (14) for the respective services; Determine whether the subscription request is granted based on a Quality of Service score assigned by the Quality of Service filter (22), and inform the requesting member of the multitude of recipients; and when the subscription application is submitted, the broker module (30) directs the relevant services. [2] System (10) of claim 1, further comprising: a second cloud unit (52) which has at least one more from the multitude of providers (12) and the multitude of recipients (14). [3] System (10) of claim 1, wherein: The Quality of Service score is a weighted sum of a priority score, a persistence score, an inter-relations score, and an authorization score; The priority score is assigned to the subscription application based on a relative importance value; the persistence score is assigned to the subscription application based on an average time that the respective services spent in the broker module (30) until consumption; the Inter-Relations score is assigned to the subscription application based on a relationship to other services of the respective providers; and the eligibility score is assigned to the subscription request based on at least one of a security factor and a trust factor assigned to the requesting member of the plurality of recipients (14). [4] System (10) of claim 1, wherein: the unified vehicle service framework (16) includes a syntax module (38) that is configured to classify the respective services as at least one of a messaging service and a calling service; the messaging service is defined as an informational message that does not require any action from the multitude of recipients (14); and the calling service is defined in such a way that it automatically triggers a predefined response from the multitude of recipients (14). [5] System (10) of claim 1, wherein the broker module (30) comprises: at least one Leaf unit configured to communicate directly with one or more of the multitude of providers (12) and the multitude of receivers (14); a root server (102) hosted by the first cloud unit (50), with the respective services registered on the root server (102); and at least one branch unit (104) configured to act as an intermediary between the root server (102) and the at least one leaf unit to route the respective services. [6] System (10) of claim 5, wherein: which are hosted by at least one Leaf unit and at least one Branch unit (104) from the first Cloud unit (50). [7] System (10) of claim 5, wherein: which are hosted by at least one Leaf unit and at least one branch unit (104) from the first vehicle (58). [8] System (10) of claim 5, wherein: the at least one branch unit (104) is configured to run several control plane modules (306), including a node child registration module (324), a node parent registration module (326), and a broker module maintenance module (322); the node child registration module (324) and the node parent registration module (326) comprise a corresponding data structure that registers one or more nodes downstream or upstream of the at least one branch unit (104) in the broker module (30); and The Broker Module Maintenance Module (322) is configured to record an entry of a new unit in the Broker Module (30) and a non-working unit in the Broker Module (30). [9] System (10) of claim 5, wherein: which is configured to run at least one branch unit (104) for multiple data layer modules (308); and the multiple data layer modules (308) contain a traffic shaping module that is configured to artificially delay traffic so that the respective services with a higher Quality of Service score can be transmitted relatively earlier. [10] System (10) of claim 9, wherein: the multiple data layer modules (308) include a virtual provider module that is configured to aggregate the respective services provided by the multitude of providers (12) into a single virtual service if the respective services have the same Quality of Service score; and The traffic shaping module is configured to treat each virtual service as a single data set.

Images