Apparatus and method for realizing dynamic service-oriented communication between vehicle applications on an AutoSurf Adaptive Platform

Abstract

The present invention relates to an apparatus and method for realizing dynamic service-oriented communication between vehicle applications on an Autoser Adaptive Platform. The machine for realizing dynamic service-oriented communication between vehicle applications on an Autoser Adaptive Platform, which is composed of an ECU with a POSIX OS implanted therein, includes a skeleton, which is an application that provides a service on the platform; a proxy, which is an application that uses a service on the platform; and a service communication manager, which is an application that mediates service-oriented communication between vehicle applications on the platform.

Description

[Technical Field]

[0001] The present invention relates to an apparatus and method for realizing dynamic service-oriented communication between vehicle applications on an AUTOSAR Adaptive Platform, and more particularly to an apparatus for realizing dynamic service-oriented communication between vehicle applications on an AUTOSAR Adaptive Platform, which is composed of platform-level applications that comprehensively manage registration and discovery of services provided or used by vehicle applications and communication for providing and using the services, and a method for dynamic service-oriented communication between vehicle applications using the apparatus. [Background technology]

[0002] The AUTOSAR standard was established in 2005 by major car manufacturers and developers to facilitate software reuse in the automotive field.

[0003] Subsequently, the need for new electrical and electronic architectures such as ECU integration was raised due to the three major issues in the automotive industry: network connectivity, autonomous driving, and electrification. As a result, the AUTOSAR Adaptive Platform (hereinafter referred to as AP), a high-performance CPU-based ECU software platform standard, was established in 2017 and has been applied to mass production since 2019.

[0004] The trend of operating vehicles on a single platform like a smartphone based on AP is progressing rapidly, and not only major global OEMs but also local OEMs are preparing to develop new ECUs that apply AP.

[0005] Unlike the AUTOSAR classic platform, which is based on signal-oriented communication, AP is based on service-oriented communication, which is a communication method in which skeletons, which are service providers, and proxies, which are service users, are dynamically connected through service discovery and SOME / IP (Scalable service-Oriented Middleware over IP).The functional cluster responsible for such service-oriented communication between AP applications is the Communication Management (CM).

[0006] Although the Autoser standard includes a specification for CM, the details are not specified, which means that implementations can vary considerably depending on the developer. The CM specification provides a structure in which applications are connected via ports, with one SOME / IP endpoint per port, but there is no limit to the number of ports. Therefore, depending on the developer's design, the number of ports can increase rapidly as the application size increases, resulting in resource waste. Furthermore, if the skeleton and proxy communicate directly, they must each have their own buffer and registry structures, which can lead to serious load issues as the application size increases. Summary of the Invention [Problem to be solved by the invention]

[0007] The present invention aims to solve the above problems by providing a device that realizes dynamic service-oriented communication between vehicle applications, which is composed of a machine (ECU with POSIX OS ported) that eliminates direct connection between skeletons and proxies and centralizes internal and external communication functions in a CM, and a service-oriented communication method using the device.

[0008] The objects of the present invention are not limited to those mentioned above, and other objects not mentioned will be clearly understood by those skilled in the art from the following description. [Means for solving the problem]

[0009] To achieve the above objective, one embodiment of the present invention provides a machine that is configured with an ECU to which a POSIX OS has been ported, and that realizes dynamic service-oriented communication between vehicle applications on an AutoServ adaptive platform, and includes: a skeleton, which is an application that provides a service on the platform; a proxy, which is an application that uses a service on the platform; and a service communication manager, which is an application that mediates service-oriented communication between vehicle applications on the platform.

[0010] The service communication manager may include a service registry that stores information about services provided by the skeleton and information about services used by the proxy; a service discovery that sends a notification of the start of service provision or a search request message (service discovery message) for use of the service via Ethernet multicast when a service registered in the service registry is to be provided to a vehicle application of another ECU or when a vehicle application of another ECU must be used; and a SOME / IP bridge that handles data communication via services provided or used by other ECUs.

[0011] The service communication manager may further include an IPC port used for communication between the skeleton and the proxy; a service discovery multicast port that sends service discovery messages generated by the service discovery to other ECUs via Ethernet multicast and receives service discovery messages sent by other ECUs via Ethernet multicast and transmits them to the service discovery; and a service endpoint port that is used for data communication between the SOME / IP bridge and other ECUs.

[0012] Meanwhile, the service endpoint port may comply with the TCP protocol or the UDP protocol.

[0013] Also, only one service communications manager can exist on the machine.

[0014] Meanwhile, the skeleton and the proxy are not directly connected to each other, and the skeleton or the proxy can communicate with the service communication manager through Inter-Process Communication (IPC).

[0015] Meanwhile, a system for realizing dynamic service-oriented communication between vehicle applications according to an embodiment of the present invention includes the machine.

[0016] Meanwhile, a method for processing an input message of a service communication manager when a service provision start notification message is input to an IPC port of the service communication manager that mediates service-oriented communication between vehicle applications according to one embodiment of the present invention includes the steps of: transmitting the message to a service registry that stores information on services provided or used within the same machine; registering the service information on the message in the service registry if the service information type is SOME / IP; generating a message to notify the start of service provision using SOME / IP and sending it to another ECU; and generating a message to notify the interruption of service provision using SOME / IP if a predetermined TTL (Time-to-Live) expires and sending it to the other ECU.

[0017] In addition, a method for processing an input message of a service communication manager when a service provision interruption notification message is input to an IPC port of the service communication manager that mediates service-oriented communication between vehicle applications according to one embodiment of the present invention includes the steps of: transmitting the message to a service registry that stores information on services provided or used within the same machine; removing the service information on the message from the service registry if the service information on the message is registered in the service registry; and generating a message to notify the interruption of service provision via SOME / IP and transmitting the message to another ECU if the type of the service information is SOME / IP.

[0018] In addition, an input message processing method of a service communication manager when a search request message for service use is input to an IPC port of the service communication manager that mediates service-oriented communication between vehicle applications according to one embodiment of the present invention includes the steps of: transmitting the message to a service registry that stores information on services provided or used within the same machine; registering the service information for the message in the service registry if the service information for the message is not registered in the service registry; and generating a search request message for service use using SOME / IP and sending it to another ECU if the type of the service information is SOME / IP.

[0019] In addition, an input message processing method of a service communication manager that mediates service-oriented communication between vehicle applications according to one embodiment of the present invention, when one of messages for providing or using an actual service is input to an IPC port of the service communication manager, includes the steps of: transmitting the message to a service registry that stores information on services provided or used within the same machine; if the ID of the service exists in the service registry, adding a SOME / IP header before the data included in the message; and sending the message with the SOME / IP header added to another ECU.

[0020] Meanwhile, in one embodiment of the present invention, when a service provision start notification message according to the SOME / IP protocol is input to a service discovery multicast port of a service communication manager that mediates service-oriented communication between vehicle applications, an input message processing method of the service communication manager includes the steps of: transmitting the message to a service registry that stores information on services provided or used within the same machine; and, if the service information related to the message is not registered in the service registry, registering the service information related to the message in the service registry.

[0021] In addition, an input message processing method of a service communication manager that mediates service-oriented communication between vehicle applications according to one embodiment of the present invention, when a search request message for using a service according to the SOME / IP protocol is input to a service discovery multicast port of the service communication manager that mediates service-oriented communication between vehicle applications, includes the steps of: transmitting the message to a service registry that stores information on services provided or used within the same machine; and, if service information related to the message is not registered in the service registry, registering the service information related to the message in the service registry.

[0022] In addition, an input message processing method of a service communication manager that mediates service-oriented communication between vehicle applications according to one embodiment of the present invention, when a service provision interruption notification message according to the SOME / IP protocol is input to a service discovery multicast port of the service communication manager that mediates service-oriented communication between vehicle applications, includes the steps of: transmitting the message to a service registry that stores information on services provided or used within the same machine; and, if service information related to the message is registered in the service registry, removing the service information related to the message from the service registry.

[0023] Meanwhile, a method for processing an input message of a service communication manager when a SOME / IP message sent by a service instance of another ECU is input to a service endpoint port of the service communication manager that mediates service-oriented communication between vehicle applications according to one embodiment of the present invention includes the steps of: searching whether the message matches a service registered in a service registry that stores information on services provided or used within the same machine; receiving an endpoint address of an application corresponding to the matched service from the service registry if the message matches a service registered in the service registry; transmitting the message and the endpoint address of the application to an IPC port of the service communication manager; and transmitting the message to a vehicle application to which the IPC port is connected.

[0024] Meanwhile, a service-oriented communication method for a skeleton, which is an application that provides a service on an AutoServ adaptive platform according to one embodiment of the present invention, includes the steps of: sending a service provision start notification message to a service communication manager, which is an application that mediates service-oriented communication between vehicle applications within the same machine as the skeleton; receiving a service request message from the service communication manager; classifying the message into a method call message (Request message) or a subscription request message (SubscribeEventGroup message) for an event message based on the parsing result of the service request message; if the service request message is the Request message as a result of the classification, calling the corresponding method and sending the resulting response message to the service communication manager; if the service request message is the SubscribeEventGroup message as a result of the classification, registering the contents of the message in a subscriber registry, and generating an event message and sending it to the service communication manager when a transmission condition for the event message is met; and if a service instance termination condition is met, generating a service provision interruption notification message and sending it to the service communication manager.

[0025] Meanwhile, a service-oriented communication method of a proxy, which is an application that uses a service on an AutoServ adaptive platform according to one embodiment of the present invention, includes the steps of: sending a search request message for using a service to a service communication manager, which is an application that mediates service-oriented communication between vehicle applications in the same machine as the proxy; receiving a response to the message from the service communication manager; selecting one service from a list of currently available services; determining a method for receiving the service; if the method for receiving the service is a method for explicitly calling a method, generating a method call message (Request message) and sending it to the service communication manager; if the method for receiving the service is a subscription to an event message, generating a subscription request message (SubscribeEventGroup message) for the event message and sending it to the service communication manager; receiving a message providing a service from the service communication manager; parsing and classifying the message providing the service; if the message providing the service is a method execution result message (Response message) as a result of the classifying, transmitting the result to the user implementation part via the caller; if the message providing the service is an event message as a result of the classification, storing the event message in an event buffer; and if a service instance termination condition is met, generating a service usage interruption notification message and sending it to the service communication manager. [Effects of the Invention]

[0026] According to one embodiment of the present invention, by centralizing the service registry and service discovery required for service mediation in the CM, the load on the application, such as memory and communication load, is reduced compared to when the skeleton and proxy each manage a buffer and registry, and appropriate service matching can be performed quickly between the skeleton and proxy.

[0027] Furthermore, according to one embodiment of the present invention, the communication function with other ECUs is centralized in the CM, thereby reducing the number of ports held by the application, thereby reducing the resources occupied by the POSIX OS, such as buffers and threads per port, which has the effect of increasing stability.

[0028] Furthermore, according to one embodiment of the present invention, since the service registry and service discovery implemented in multiple applications are handled in one process, the size of the program can be reduced when compiled. [Brief explanation of the drawings]

[0029] [Figure 1] 1 is a diagram showing the configuration and connection structure of a device that realizes dynamic service-oriented communication between vehicle applications in an AutoSurface Adaptive Platform. [Figure 2] FIG. 1 is a diagram illustrating the configuration of a service communication manager. [Figure 3a] 10 is a flowchart for explaining a processing method when an OfferService message among service discovery messages is input to an IPC port of a service communications manager. [Figure 3b] 10 is a flowchart for explaining a processing method when a StopOfferService message among service discovery messages is input to an IPC port of a service communications manager. [Figure 3c] 10 is a flowchart for explaining a processing method when a FindService message among service discovery messages is input to an IPC port of a service communications manager. [Figure 4] 10 is a flowchart for explaining a processing method when a service message is input to an IPC port of a service communications manager. [Figure 5a]10 is a flowchart for explaining a processing method when a SOME / IP service discovery OfferService message is input to a SOME / IP service discovery multicast port of a service communications manager. [Figure 5b] 10 is a flowchart for explaining a processing method when a SOME / IP service discovery StopOfferService message is input to a SOME / IP service discovery multicast port of a service communications manager. [Figure 6] 10 is a flowchart for explaining a processing method when a message is input to a SOME / IP service endpoint port of a service communications manager. [Figure 7] 1 is a flowchart illustrating a skeleton service-oriented communication method. [Figure 8] 1 is a flowchart illustrating a service-oriented communication method for a proxy. DETAILED DESCRIPTION OF THE INVENTION

[0030] The advantages and features of the present invention, as well as methods for achieving them, will become clearer with reference to the following detailed description of the embodiments in conjunction with the accompanying drawings. However, the present invention is not limited to the embodiments disclosed below and may be embodied in various different forms. These embodiments are provided so that this disclosure will be complete and will fully convey the scope of the invention to those skilled in the art. The present invention is defined solely by the scope of the claims. Meanwhile, terms used in this specification are for the purpose of describing the embodiments only and are not intended to limit the scope of the present invention. In this specification, the singular includes the plural unless otherwise specified. When used in the specification, the terms "comprises" and / or "comprising" do not exclude the presence or addition of one or more other components, steps, operations, and / or elements to a referenced component, step, operation, and / or element. Hereinafter, an apparatus and method for realizing dynamic service-oriented communication between vehicle applications in an AutoSmart adaptive platform according to the present invention will be described.

[0031] FIG. 1 is a diagram illustrating the configuration and connection structure of a device for realizing dynamic service-oriented communication between vehicle applications in an AutoSAR adaptive platform according to an embodiment of the present invention.

[0032] Basically, a system for realizing dynamic service-oriented communication between vehicle applications has a structure in which multiple machines 110-1 to 110-n are connected to a single vehicle 100 via ports 172 and 182 and the vehicle's Ethernet 190. A machine (110-1 to 110-n) is an AP term and refers to an ECU to which a POSIX OS has been ported. While the system includes at least one machine, ECUs that are not machines can also be included in the system, and applications in the ECUs that are not machines can provide services to applications in the system's machines or use the services of applications in the system's machines. Each machine (one of 110-1 to 110-n, hereinafter referred to as 110) includes a skeleton (120), a proxy (140), and a service communication manager (CM) (150). The skeleton 120 is a vehicle application that provides a service and is a POSIX process with a service provider instance that embodies the role of the service provider. The proxy 140 is a vehicle application that uses a service and is a POSIX process having a service consumer instance that embodies the role of a service user. Multiple skeletons 120 and proxies 140 can exist on one machine 110. Also, one application can be both a skeleton 120 and a proxy 140. The CM 150 is a platform application that mediates service-oriented communication between vehicle applications. Only one CM 150 is allowed on one machine 110. The skeleton 120 or proxy 140 contained in one machine 110 communicates with the CM 150 contained in the same machine 110 via IPC (Inter-Process Communication). The skeletons 120 and proxies 140 contained in the same machine 110 are not directly connected to each other.

[0033] The skeleton 120 has a service provider port (122) which is a communication port for providing a service. The skeleton 120 transmits a communication setting command for the service to be provided and data used in connection with the service to the CM 150 through the service provider port 122.

[0034] The proxy 140 has a service consumer port (142) which is a communication port for using a service. The proxy 140 transmits a communication setting command for the service to be used and data used in connection with the service to the CM 150 through the service consumer port 142.

[0035] The CM 150 has an IPC port (Inter-Process Communication port, 152) to process requests from each vehicle application. The CM 150 receives data sent from the vehicle application through the IPC port 152, processes the received data, and sends it to the target application.

[0036] The CM 150 has a SOME / IP service discovery multicast port (hereinafter referred to as SD multicast port) 172 and a SOME / IP service endpoint port (hereinafter referred to as service endpoint port) 182 to communicate with other ECUs (other ECUs physically separated within the same vehicle). The ports 172 and 182 are connected to the vehicle's Ethernet 190.

[0037] 2 is a block diagram of a CM 150 according to an embodiment of the present invention. As shown in FIG. 2, the CM 150 includes a service registry (160), a service discovery (170), a SOME / IP bridge (180), an IPC port 152, an SD multicast port 172, a SOME / IP remote TCP port (hereinafter referred to as TCP port 182a), and a SOME / IP remote UDP port (hereinafter referred to as UDP port 182b). The TCP port 182a and the UDP port 182b correspond to the service endpoint port 182.

[0038] The CM 150 has an IPC port 152 for communication with the skeleton 120 and proxy 140 that reside on the same machine 110 .

[0039] The IPC port 152 is a port for communication between the skeleton 120 and the proxy 140 that exist on the same machine 110. If the type of the received message is a service discovery message, the IPC port 152 transmits the message to the service registry 160. If the message is a service message and the service ID exists in the service registry 160, the IPC port 152 transmits the message to the SOME / IP bridge 180.

[0040] Service registry 160 is a data structure that stores information about services provided by skeleton 120 within machine 110 or used by proxy 140 .

[0041] When the service registry 160 receives an OfferService message (hereinafter also referred to as an "OfferService message") for a service or a FindService message (a search request message for using a service) from the IPC port 152 or the SD multicast port 172, it checks whether the corresponding service information is registered in the service registry 160, and if the service is not registered in the existing table, it registers the information for the corresponding service in the table. In addition, the service registry 160 determines the type of newly registered service information, and if it is an IPC type, it does not transfer the service registration information to the service discovery 170, but if it is a SOME / IP type, it transfers the service registration information to the service discovery 170.

[0042] When the service registry 160 receives a service provision interruption notification message (StopOfferService message), it checks whether the corresponding service information is registered in the service registry 160. If the information is registered in the service registry 160, the service registry 160 removes the information from the table. If the information is not registered in the service registry 160, the service registry 160 determines the type of the service information. If the service information is an IPC type, it does not transmit the service information to the service discovery 170, and if the service information is a SOME / IP type, it transmits the service information to the service discovery 170.

[0043] When a service registered in the service registry 160 needs to be provided to a vehicle application in another ECU or when a vehicle application in another ECU needs to be used, the service discovery 170 transmits a message regarding such service provision / use via Ethernet multicast. The service discovery 170 also receives service provision and search request messages regarding services registered in other ECUs. For this purpose, the service discovery 170 has an SD multicast port 172 bound to Ethernet multicast. Service-oriented communication between APs is achieved by multiple services joining a common Ethernet multicast. The SD multicast port 172 transmits service discovery messages generated by the service discovery 170 to other ECUs via Ethernet multicast connected to it, and receives SOME / IP service discovery messages transmitted by other ECUs via Ethernet multicast connected to it and transmits them to the service discovery 170.

[0044] If the TTL expires after generating and transmitting a SOME / IP SD OfferService message, or if the TTL expires after generating and transmitting a SOME / IP SD FindService message, the service discovery 170 suspends the instance of the corresponding service. Also, if a StopOfferService is requested by the skeleton 120 even before the TTL expires, the service discovery 170 creates a SOME / IP SD StopOfferService message based on the corresponding service information, transmits the message via Ethernet multicast, and then suspends the instance of the corresponding service.

[0045] The SOME / IP bridge 180 is an instance dynamically created by the service discovery 170 when a registered service requests the transmission and reception of data required for service processing using the SOME / IP protocol. A single or multiple SOME / IP bridges 180 can be created. The SOME / IP bridge 180 is responsible for data communication with services provided by or used by other ECUs. For this purpose, each SOME / IP bridge 180 has a TCP port 182a and a UDP port 182b. When the SOME / IP bridge 180 receives network endpoint information from the service discovery 170, it opens POSIX Ethernet sockets, TCP port 182a and UDP port 182b, based on this information. The required network endpoint information is the IP address, port number, and protocol information used by the SOME / IP-based service instance. Only TCP or UDP is allowed as the protocol.

[0046] In addition, when a service message is transmitted from the IPC port 152, the SOME / IP bridge 180 adds a SOME / IP header to the data and then transmits the SOME / IP message to the TCP port 182a or the UDP port 182b so that the SOME / IP message can be sent through the port.

[0047] Furthermore, when SOME / IP bridge 180 receives a SOME / IP message transmitted by a service instance of another ECU via TCP port 182a or UDP port 182b, it checks whether the received SOME / IP message matches a service registered in service registry 160. If the message matches a service registered in service registry 160, SOME / IP bridge 180 receives an endpoint address of an application corresponding to the matched service from service registry 160. SOME / IP bridge 180 transmits the message and the application endpoint address to IPC port 152, thereby enabling IPC port 152 to send the message to the skeleton 120 or proxy 140 connected to it.

[0048] 3a, 3b, 3c, and 4 are flowcharts illustrating a processing method of CM 150 according to the type and content of each message when a message is input to IPC port 152 of CM 150. Prior to describing the drawings, the message types received at IPC port 152 will be described.

[0049] The types of messages received by the IPC port 152 are divided into (1) service discovery messages and (2) service messages. (1) Service discovery messages are messages that vehicle applications use to start or stop providing a service or to request a search for using a service. (2) Service messages are messages sent and received between connected service instances after a service has been registered to actually provide and use the service. The IPC port 152 distinguishes between (1) and (2) using a protocol header.

[0050] When the skeleton 120 starts providing a service or suspends providing a service using the service provision API, the skeleton 120 generates a service discovery message and sends it to the CM 150. When the skeleton 120 starts providing a service, it generates an OfferService message and sends it to the CM 150, and when the skeleton 120 suspends providing a service, it generates a StopOfferService message and sends it to the CM 150.

[0051] When the proxy 140 starts a service search using the service search API, the proxy 140 generates a FindService message, which is one of service discovery messages, and transmits it to the CM 150 .

[0052] When the IPC port 152 receives a service discovery message, it communicates the message to the service registry 160 .

[0053] When the IPC port 152 receives a service message, it checks whether the service ID of the service message exists in the service registry 160. If it exists, it transfers the service message to the SOME / IP bridge 180.

[0054] FIG. 3a is a flowchart illustrating a processing method when an OfferService message among service discovery messages is input to the IPC port 152 of the CM 150 according to an embodiment of the present invention.

[0055] In step S110, since the OfferService message is a service discovery message, the IPC port 152 transmits this message to the service registry 160.

[0056] In step S112, the service registry 160 checks whether the service information related to the OfferService message is registered.

[0057] In step S114, if the service information regarding the OfferService message has already been registered in the service registry 160, the service is ignored without being registered. If the service information regarding the OfferService message has not been registered in the service registry 160, step S116 is performed.

[0058] In step S116, the service registry 160 registers service information related to the OfferService message, including the instance identifier, service ID, instance ID, version information, and network endpoint information of the application for the service to be offered, as a tuple in a table.

[0059] In step S118, the service registry 160 determines the type of the registered service information. If it is an IPC type, the service registry 160 does not transmit the registered information to the service discovery 170. If it is a SOME / IP type, the service registry 160 performs step S120.

[0060] In step S120, the service registry 160 transmits the registration information to the service discovery 170.

[0061] In step S122, the information received by the service discovery 170 is derived from the OfferService message, so the service discovery 170 generates a SOME / IP service discovery OfferService message (hereinafter, SOME / IP SD OfferService message).

[0062] In step S124, the service discovery 170 creates a SOME / IP bridge 180 instance to process the message.

[0063] In step S126, the service discovery 170 transmits the network endpoint information received from the service registry 160 to the SOME / IP bridge 180.

[0064] In step S128, the SOME / IP bridge 180 opens a TCP port 182a and a UDP port 182b, which are POSIX Ethernet sockets, based on the network endpoint information. At this time, the required network endpoint information is the IP address, port number, and protocol information used by the SOME / IP-based service instance. Only TCP or UDP is allowed as the protocol.

[0065] The transmission / waiting of the generated SOME / IP SD OfferService message is divided into an initial wait phase (S130), a repetition phase (S132), and a main phase (S134).

[0066] In step S130, the service discovery 170 waits for a time specified in the information transmitted from the service registry 160, and then transmits a SOME / IP SD OfferService message to the connected Ethernet multicast through the SD multicast port 172.

[0067] In step S132, the service discovery 170 waits for a time specified in the information transmitted from the service registry 160, and then transmits a SOME / IP SD OfferService message to the connected Ethernet multicast through the SD multicast port 172.

[0068] In step S134, the service discovery 170 transmits a SOME / IP SD OfferService message to the connected Ethernet multicast through the SD multicast port 172 according to the period specified in the information received from the service registry 160.

[0069] In step S136, it is checked whether the specified TTL has expired, and if not, step S134 is continued, otherwise step S138 is performed.

[0070] In step S138, the service discovery 170 generates a SOME / IP service discovery StopOfferService message (hereinafter referred to as SOME / IP SD StopOfferService message) based on the corresponding service information and transmits the message to the connected Ethernet multicast through the SD multicast port 172 (S140).

[0071] In step S142, the service discovery 170 suspends the instance of the corresponding service.

[0072] If a StopOfferService is requested in the skeleton 120 even before the specified TTL expires, the description regarding FIG. 3b is followed (S150 to S166).

[0073] FIG. 3b is a flowchart illustrating a processing method when a StopOfferService message among service discovery messages is input to the IPC port 152 of the CM 150 according to an embodiment of the present invention.

[0074] In step S150, since the StopOfferService message is a service discovery message, the IPC port 152 transmits this message to the service registry 160.

[0075] At step S152, the service registry 160 removes this information from its table.

[0076] In step S154, the service registry 160 determines the type of the service information. If the service information is an IPC type, the service registry 160 does not transmit the service information to the service discovery 170. If the service information is a SOME / IP type, the service registry 160 proceeds to step S156.

[0077] In step S156, the service registry 160 transmits the service information to the service discovery 170.

[0078] In step S158, since the information received by the service discovery 170 is derived from the StopOfferService message, the service discovery 170 generates a SOME / IP SD StopOfferService message.

[0079] In step S160, the service discovery 170 transmits the message to the Ethernet multicast through the SD multicast port 172.

[0080] In step S162, the service discovery 170 suspends the corresponding service instance.

[0081] FIG. 3c is a flowchart illustrating a processing method when a FindService message among service discovery messages is input to the IPC port 152 of the CM 150 according to an embodiment of the present invention.

[0082] In step S170, since the FindService message is a service discovery message, the IPC port 152 transmits this message to the service registry 160.

[0083] In step S172, the service registry 160 checks whether the service information related to the FindService message is registered.

[0084] In step S174, if the service information related to the FindService message has already been registered in the service registry 160, the service is ignored without being registered. If the service information related to the FindService message has not been registered in the service registry 160, step S176 is performed.

[0085] In step S176, the service registry 160 registers service information related to the FindService message, including the instance identifier of the search target service, the service ID, the requested instance ID, the requested version information, and the network endpoint information of the application, as a tuple in a table.

[0086] In step S178, the service registry 160 determines the type of the registered service information. If it is an IPC type, the service registry 160 does not transmit the registered information to the service discovery 170. If it is a SOME / IP type, the service registry 160 proceeds to step S180.

[0087] In step S180, the service registry 160 transmits the registration information to the service discovery 170.

[0088] In step S182, since the information received by the service discovery 170 is derived from the FindService message, the service discovery 170 generates a SOME / IP service discovery FindService message (hereinafter, SOME / IP SD FindService message).

[0089] In step S184, to process the message, the service discovery 170 creates an instance of the SOME / IP bridge 180. At this time, the service discovery 170 transfers the network endpoint information received from the service registry 160 to the SOME / IP bridge 180 (S186).

[0090] In step S188, the SOME / IP bridge 180 opens POSIX Ethernet sockets, TCP port 182a and UDP port 182b, based on the network endpoint information. At this time, the required network endpoint information is the IP address, port number, and protocol information used by the SOME / IP-based service instance. Only TCP or UDP is allowed as the protocol.

[0091] The transmission / waiting of the generated SOME / IP SD FindService message is divided into an initial wait phase (S190), a repetition phase (S192), and a main phase (S194).

[0092] In step S190, the service discovery 170 waits for a time specified in the information transmitted from the service registry 160, and then sends a SOME / IP SD FindService message to the connected Ethernet multicast through the SD multicast port 172.

[0093] In step S192, the service discovery 170 waits for the time specified in the information transmitted from the service registry 160, and then sends a SOME / IP SD FindService message to the connected Ethernet multicast through the SD multicast port 172.

[0094] In step S194, the service discovery 170 waits without sending a SOME / IP SD FindService message.

[0095] In step S196, it is checked whether the specified TTL has expired, and if not, step S194 is continued, otherwise step S198 is performed.

[0096] In step S198, the service discovery 170 suspends the corresponding service instance.

[0097] FIG. 4 is a flowchart illustrating a processing method when a service message is input to the IPC port 152 of the CM 150 according to an embodiment of the present invention.

[0098] In step S210, if the received message is a service message, the IPC port 152 searches the service registry 160 to see if the service ID is present.

[0099] If the service ID exists in the service registry 160 in step S220, the SOME / IP bridge 180 must have been created, and step S230 is performed.

[0100] In step S230, the IPC port 152 transmits the service message to the SOME / IP bridge 180.

[0101] In step S240, the SOME / IP bridge 180 adds a SOME / IP header in front of the transmitted data.

[0102] In step S250, the SOME / IP bridge 180 transfers the SOME / IP message to the TCP port 182a or the UDP port 182b, and transmits the SOME / IP message to another ECU through the port (S260).

[0103] FIG. 5a is a flowchart illustrating a processing method when a SOME / IP SD OfferService message is input to the SD multicast port 172 of the CM 150 according to an embodiment of the present invention.

[0104] In step S310, the SD multicast port 172 receives a SOME / IP service discovery message (hereinafter, SOME / IP SD message) to be sent to another ECU through the connected Ethernet multicast and transfers it to the service discovery 170.

[0105] In step S312, the service discovery 170 transmits the received message to the service registry 160 if the message is a SOME / IP SD OfferService.

[0106] In step S314, the service registry 160 checks whether service information related to the message is registered.

[0107] In step S316, if the service information related to the message has already been registered in the service registry, the service is ignored without being registered, and if not, step S318 is performed.

[0108] In step S318, the service registry 160 treats the service information related to the message as newly provided service information, creates a tuple, and registers it.

[0109] The message processing method of S310 to S318 described above is also applied when the message input to the SD multicast port 172 is a SOME / IP SD FindService.

[0110] FIG. 5b is a flowchart illustrating a processing method when a SOME / IP SD StopOfferService message is input to the SD multicast port 172 of the CM 150 according to an embodiment of the present invention.

[0111] In step S330, the SD multicast port 172 receives a SOME / IP service discovery message (hereinafter, SOME / IP SD message) to be sent to another ECU through the connected Ethernet multicast and transfers it to the service discovery 170.

[0112] In step S332, the service discovery 170 transmits the received message to the service registry 160 if the message is a SOME / IP SD StopOfferService.

[0113] In step S334, the service registry 160 checks whether service information related to the message is registered.

[0114] If the service information related to the message is not registered in the service registry in step S336, the information is ignored, otherwise step S338 is performed.

[0115] In step S338, the service registry 160 removes the registered service information tuple associated with the message.

[0116] 6 is a flowchart illustrating a processing method when a message is input to the service endpoint port 182 of the CM 150 according to an embodiment of the present invention. The TCP port 182a and the UDP port 182b correspond to the service endpoint port 182.

[0117] In step S410 , the service endpoint port 182 receives a SOME / IP message sent by a service instance of another ECU through the connected Ethernet and transfers the message to the SOME / IP bridge 180 .

[0118] In step S420, the SOME / IP bridge 180 checks whether the received SOME / IP message matches a service registered in the service registry 160. If the message matches a service registered in the service registry 160, step S430 is performed.

[0119] In step S430, the service registry 160 notifies the SOME / IP bridge 180 of the endpoint address of the application corresponding to the matched service.

[0120] In step S440, the SOME / IP bridge 180 transfers the received message and the application's endpoint address to the IPC port 152.

[0121] In step S450, the IPC port 152 transmits the message to the skeleton 120 or proxy 140 connected to it.

[0122] 7 is a flowchart illustrating a service-oriented communication method of a skeleton 120 according to an embodiment of the present invention. It can be roughly divided into an "initialization" part that initializes a service provider instance, a "service provision" part that processes service data communication after service registration and search are completed, and a "termination" part that performs termination of a service provider instance.

[0123] The "Initialize" part is where the service instance is initialized.

[0124] In step S510, the manifest, which is the service configuration file, is decoded, and the service ID, instance ID, service version, and service information type (IPC or SOME / IP) can be identified.

[0125] In step S512, an OfferService message to be transmitted to the CM 150 is generated.

[0126] In step S514, the skeleton 120 sets and opens an endpoint for communication with the CM 150.

[0127] In step S516, an OfferService message is sent to the CM 150 through the service provider port 122 of the skeleton 120. The OfferService message is a service discovery message, which means that the application provides a service.

[0128] The "service provision" part begins when the CM 150 completes initialization of the service registry 160 and service discovery 170 related to the service provision. However, if the type of information of the service to be provided is SOME / IP, the part does not begin until the SOME / IP bridge 180 has also completed initialization. In the service provision part, the proxy 140 receives a message from the CM 150, processes the requested service, and sends a result message to the CM 150.

[0129] In step S530, a service message (a message requesting a service) is received from the CM.

[0130] In step S532, the received message is parsed.

[0131] In step S534, the received message is divided into two types based on the parsing result. The first is a Request message that calls a method (a function provided by the service), and the second is a SubscribeEventGroup message that attempts to subscribe to an Event message unilaterally generated and sent by the service. If the received message is a Request message, step S540 is performed, and if it is a SubscribeEventGroup message, step S550 is performed.

[0132] In step S540, the received message is deserialized, and parameters are separated to use the functions provided by the method.

[0133] In step S542, the method is called by inputting the parameters. If a response is required from the proxy 140 that requested the service, the called method generates a Response message.

[0134] In step S544, the generated Response message is serialized.

[0135] In step S546, the serialized Response message is sent to the CM 150 through the service provider port 122 of the skeleton 120.

[0136] In step S550, the message content is registered in the subscriber registry, which is information about subscribers who can receive the event message provided by the service.

[0137] In step S552, it is determined whether the event message can be transmitted. If the event message can be transmitted, step S554 is performed. If the event message cannot be transmitted, step S564 is performed.

[0138] In step S554, a SubscribeEventgroupAck message, which is a service discovery message, is transmitted.

[0139] In step S556, it is determined whether the conditions for sending the event message to the subscriber have been met. If the conditions have been met, the process proceeds to step S558.

[0140] In step S558, an Event message is generated. The Event message may include data implemented by a user. The term "user" refers to a subject that uses the device (e.g., machine) of the present invention, and shall be interpreted in the same sense hereinafter.

[0141] In step S560, the Event message is serialized.

[0142] In step S562, the serialized Event message is sent to the CM 150 through the service provider port 122 of the skeleton 120.

[0143] In step S564, a SubscribeEventgroupNack message, which is a service discovery message, is sent, and no further Event messages are sent to the corresponding subscriber.

[0144] The "end" section is the section that ends the service instance.

[0145] If the conditions for terminating the service instance are met, a StopOfferService message is generated in step S570. The StopOfferService message is a service discovery message that indicates that the provision of the service is to be terminated.

[0146] In step S572, a StopOfferService message is sent to the CM 150 through the service provider port 122 of the skeleton 120.

[0147] 8 is a flowchart illustrating a service-oriented communication method of a proxy 140 according to an embodiment of the present invention. The method can be broadly divided into an "initialization" part that initializes a service consumer instance, a "service usage" part that processes service data communication after service search is completed, and a "termination" part that terminates the service consumer instance.

[0148] The "initialization" section is where the service instance is initialized.

[0149] In step S610, the manifest, which is the service configuration file, is decoded, and the ID of the service to be searched, the ID of the requested instance, the version of the requested service, and whether the type of service information is IPC or SOME / IP can be determined.

[0150] In step S612, a FindService message to be transmitted to the CM 150 is generated.

[0151] In step S614, the proxy 140 sets and opens an endpoint for communication with the CM 150.

[0152] In step S616, the proxy 140 sends a FindService message to the CM 150 through the service consumer port 142. The FindService message is a service discovery message that searches whether the service the application wants to use is currently being provided. After sending the FindService message to the CM 150, the proxy 140 waits for a response from the CM 150.

[0153] If a response (search result) is received from the CM 150 (S618), the proxy handler sorts the list of currently available services and notifies the application whether a service is searched and the items of the searched services in step S620.

[0154] In step S622, the application selects one of the available services.

[0155] The 'service usage' part begins when the service registry 160 and service discovery 170 complete initialization after the service search in the CM 150 and connection between the proxy 140 and the CM 150 are complete. However, if the service type used by the proxy 140 is SOME / IP, the 'service usage' part does not begin until the SOME / IP bridge 180 also completes initialization. In the 'service usage' part, the proxy 140 sends a message to the CM 150 requesting the required service, and receives and processes a result message from the CM 150.

[0156] Step S630 branches to step S640 or step S650 depending on how the proxy 140 receives the service. The proxy 140 uses a method of the skeleton 120 via the CM 150 through a method caller. There are two ways for the proxy 140 to use the method of the skeleton 120: (1) explicitly calling the method of the skeleton 120, or (2) subscribing to a specific event of the skeleton 120. The choice of (1) or (2) depends on the logic implemented in the application by the user. If (1) is selected, step S640 is performed, and if (2) is selected, step S650 is performed.

[0157] In step S640, a Request message is generated by including input parameters of the method to be invoked through the method caller.

[0158] In step S642, the generated Request message is serialized.

[0159] In step S644, the serialized Request message is sent to the CM 150 through the service consumer port of the proxy 140. After sending, the method caller waits until a Response message is received from the CM.

[0160] In step S650, an event to be subscribed to is designated through an event subscriber, and a SubscribeEventgroup message, which is a service discovery message, is generated.

[0161] In step S652, the message is sent to the CM 150 through the service consumer port 142 of the proxy 140.

[0162] In step S660, a service message is received from the CM.

[0163] In step S662, the received message is parsed.

[0164] In step S664, the parsed message is divided into two cases and branched accordingly. The first case is when a request message for a method was previously sent from the proxy 140 and a Response message, which is the result of the method execution, is received. The second case is when an Event message for an event for which a subscription has been set is received. In the first case, S670 is performed, and in the second case, S680 is performed.

[0165] In step S670, the Response message is transmitted to the method caller that is waiting for the Response message.

[0166] In step S672, the method caller transmits the result to the user-implemented part of the proxy 140.

[0167] In step S680, the event message is stored in the event buffer as is.

[0168] In step S682, the stored event message is used. The event message can be used by the proxy 140 in the following two ways. First, the proxy 140 implementer extracts and uses the event message stored in the event buffer at a specific time. The event buffer has a first-in, first-out data structure, and becomes empty when an event message is extracted. Second, the proxy 140 implementer binds a callback function. In this way, the bound callback function is called every time an event message is stored in the event buffer, and the implementer can decide whether to extract the stored event message at this point.

[0169] The "end" section is the section that ends the service instance.

[0170] If the conditions for terminating the service instance are met, the proxy 140 generates a StopFindService message in step S690. The StopFindService message indicates that the proxy 140 will discontinue use of the service.

[0171] In step S692, the proxy 140 sends a StopFindService message to the CM 150 through the service consumer port 142. When the CM 150 receives the StopFindService message, it releases the associated information and instances that have been registered and activated in the service registry 160, the service discovery 170, and the SOME / IP bridge 180 (in the case of a SOME / IP service).

[0172] In addition, components according to the embodiments of the present invention can be implemented in the form of software or hardware such as a Field Programmable Gate Array (FPGA) or an Application Specific Integrated Circuit (ASIC) to perform a predetermined function.

[0173] However, the term "component" is not limited to software or hardware, and each component may be configured to reside on an addressable storage medium and to run on one or more processors.

[0174] Thus, by way of example, components include components such as software components, object-oriented software components, class components, and task components, as well as processes, functions, attributes, procedures, subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0175] The components and the functionality provided within those components may be combined into fewer components or further separated into additional components.

[0176] It will be understood that each block of the process flowchart diagrams and combinations of flowchart diagrams can be implemented by computer program instructions. These computer program instructions can be loaded into a processor in a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that the instructions, executed by the processor in the computer or other programmable data processing device, create means for performing the functions described in one or more of the flowchart blocks. These computer program instructions can be used to direct a computer or other programmable data processing device to implement the functions in a particular way, or can be stored in computer-readable memory, such that the computer can be used to produce an article of manufacture containing instruction means for performing the functions described in one or more of the flowchart blocks. The computer program instructions may be embodied on a computer or other programmable data processing device such that a series of operational steps are performed on the computer or other programmable data processing device to create a computer-implemented process, and the instructions that cause the computer or other programmable data processing device to provide steps for performing the functions described in one or more of the flowchart blocks.

[0177] Also, each block may represent a module, segment, or portion of code that includes one or more executable instructions for performing one or more specified logical functions. Also, it should be noted that in some alternative implementations, the functions noted in the blocks may occur in a different order. For example, two blocks shown in succession may be performed substantially simultaneously, or the blocks may sometimes be performed in reverse order depending on the corresponding functions.

[0178] The processing method when a message is input to a port of the CM 150, the service-oriented communication method of the skeleton 120, and the service-oriented communication method of the proxy 140 have been described with reference to the flowcharts shown in the drawings. For ease of explanation, the methods have been illustrated and described using a series of blocks. However, the present invention is not limited to the order of the blocks. Some blocks may occur in a different order or simultaneously with other blocks than those illustrated and described herein. Various other branches, flow paths, and block orders may be implemented that achieve the same or similar results. Also, not all illustrated blocks may be required to implement the methods described herein.

[0179] Although the configuration of the present invention has been described in detail above with reference to the accompanying drawings, it should be understood that this is merely an example, and that those skilled in the art will recognize that various modifications and changes may be made within the scope of the technical concept of the present invention. Therefore, the scope of protection of the present invention should not be limited to the above-described embodiments, but should be defined by the following claims.

Claims

1. A machine that is configured with an ECU to which the POSIX OS has been ported and that realizes dynamic service-oriented communication between vehicle applications on an AutoServ adaptive platform, Skeleton, an application that provides services on the platform; A proxy is an application that uses services on the platform; and a service communication manager, which is an application that mediates service-oriented communication between vehicle applications on the platform; The service communications manager: a service registry that stores information about services provided by the skeleton and services used by the proxy; A service discovery function that transmits a service provision start notification or a search request message (service discovery message) for using the service through Ethernet multicast when the service registered in the service registry is to be provided to a vehicle application of another ECU or when a vehicle application of another ECU needs to be used; SOME / IP Bridge, which is responsible for data communication via services provided and used by other ECUs; The IPC port used for communication between the skeleton and the proxy; a service discovery multicast port that transmits a service discovery message generated by the service discovery to other ECUs via Ethernet multicast and receives a service discovery message transmitted by another ECU via Ethernet multicast and transmits the received message to the service discovery; and A service endpoint port used for data communication between the SOME / IP bridge and other ECUs; The skeleton and the proxy are not directly connected to each other, and the skeleton or the proxy communicates with the service communication manager through IPC (Inter-Process Communication); The IPC port is If the message received from the skeleton or the proxy is a service discovery message, communicating the received message to the service registry; If the message received from the skeleton or the proxy is a service message, and if the service ID of the received message exists in the service registry, deliver the received message to the SOME / IP bridge; The SOME / IP bridge comprises: When a service message is delivered from the IPC port, a SOME / IP message is generated from the delivered service message, and the generated SOME / IP message is delivered to the service endpoint port; The service endpoint port is Sending the SOME / IP message transmitted from the SOME / IP bridge to another ECU; The service registry When a service discovery message is transmitted from the IPC port, If the transmitted service discovery message is a provision start notification message for a service, it is checked whether service information related to the transmitted service discovery message is registered in the service registry. If the service information is not registered, it registers service information including an instance identifier, a service ID, an instance ID, version information, and network endpoint information of the application of the service to be provided as a tuple in a table. If the transmitted service discovery message is a search request message for using a service, it is determined whether service information related to the transmitted service discovery message is registered in the service registry. If the service information is not registered, it registers service information including an instance identifier of the service to be searched, a service ID, a requested instance ID, requested version information, and network endpoint information of the application as a tuple in a table. If the transmitted service discovery message is a service provision interruption notification message, it is determined whether service information related to the transmitted service discovery message is registered in the service registry, and if the service information is registered, it removes the registered service information from a table; determining a type of service information related to the transmitted service discovery message, and if the type of service information related to the transmitted service discovery message is an IPC type, not transmitting the service information related to the transmitted service discovery message to the service discovery; and if the type of service information related to the transmitted service discovery message is a SOME / IP type, transmitting the service information related to the transmitted service discovery message to the service discovery; The service discovery includes: If the received service discovery message is a service provision start notification message for a service, generating a SOME / IP service discovery provision start notification message based on service information related to the service provision start notification message; If the received service discovery message is a search request message for using a service, a SOME / IP service discovery search request message is generated based on service information related to the search request message; If the received service discovery message is a service provision interruption notification message, generating a SOME / IP service discovery service provision interruption notification message based on service information related to the service provision interruption notification message; The service discovery multicast port is A machine that transmits a SOME / IP service discovery provision start notification message, a SOME / IP service discovery search request message, or a SOME / IP service discovery service provision interruption notification message generated in the service discovery to another ECU.

2. The machine of claim 1 , wherein the service endpoint port complies with a TCP protocol or a UDP protocol.

3. The service communications manager 2. The machine of claim 1, wherein there is only one of said machines.

4. A system for realizing dynamic service-oriented communication between vehicle applications, the system comprising a machine according to any one of claims 1 to 3.

Images