KR20200003716A - Method and device for inter-process communication in a network - Google Patents

Abstract

The present disclosure relates to a system for communicating between processes in a network and applications thereof. According to an embodiment of the present disclosure, a communication method comprises the steps of: inspecting a registration request of a source application for communicating with a destination application; determining, according to the inspection result, a port for communicating with the destination application; transmitting a communication request to the destination application through the determined port; and causing the source application to connect with the destination application based on the communication request.

Description

Interprocess communication method and device in network {METHOD AND DEVICE FOR INTER-PROCESS COMMUNICATION IN A NETWORK}

Embodiments relate to a method and a device for interprocess communication in a network, and more particularly, to a method and an apparatus in which an application uses the network to perform security-enhanced communication with another application.

A communication protocol is a system of rules for sending and receiving messages between computers and telecommunication equipment. Information exchanged between devices over the network is managed according to rules that can be set in the communication protocol specification. To implement the networking protocol, the protocol software module is interfaced with a framework implemented in the machine's operating system. As a framework, the Transmission Control Protocol / Internet Protocol (TCP / IP) model or the Open Systems Interconnection (OSI) model can be used.

Such existing communication protocols cannot accommodate the next generation technology due to latency and bandwidth requirements. In addition, the implementation of existing protocols involves the use of complex physical wiring and complex topologies. Ethernet is the physical layer that can solve these problems, but because it requires the IP address of each Electric Control Unit (ECU) that the system wants to communicate with, it uses a dedicated port for a particular protocol. Is susceptible to attack

Therefore, there is a need for research on interprocess communication techniques that can solve the above or other disadvantages or at least provide a useful alternative.

Disclosure of Invention Problems to be solved by the present disclosure are to solve the above-described problem, and to provide a method and a device for inter-process communication in a single network to efficiently securely communicate.

In addition, a computer program product comprising a computer readable recording medium having recorded thereon a program for executing the method on a computer. Technical problem to be solved is not limited to the technical problem as described above, there may be another technical problem.

As a technical means for achieving the above-described technical problem, an embodiment of the present disclosure, a memory for storing one or more instructions, at least one processor for executing the one or more instructions, wherein the at least one processor, Validating a registration request of a source application for communicating with a destination application, determining a port for communicating with the destination application, sending a communication request to the destination application through the determined port, according to the check result; Provide the electronic device configured to connect the source application with the destination application based on the communication request.

In one embodiment, the registration request may provide an electronic device comprising at least one of a name of the destination application and a desired quality of services (QoS).

In one embodiment, the at least one processor may provide the electronic device, further configured to register the source application with a network through the first library of source applications based on the registration request.

In one embodiment, the at least one processor is further configured to recursively forward the communication request to at least one communication stack until the communication request reaches a physical layer. Configured, an electronic device can be provided.

In one embodiment, the at least one processor is further configured to recursively transmit the communication request to one or more Ethernet switches until the communication request reaches a processor controlling the destination application. Can be provided.

In one embodiment, the at least one processor may provide an electronic device, further configured to dynamically determine the port.

In one embodiment, the at least one processor is further configured to determine a port identifier indicative of the determined port, wherein the port identifier indicative of the determined port comprises a port number dynamically assigned by the second library of the source application. It can provide an electronic device, including.

In one embodiment, the at least one processor may provide the electronic device, further configured to send the registration request from the first library to the second library of the source application.

In one embodiment, the registration request may provide an electronic device that includes an encrypted name and an authentication key of the destination application.

In one embodiment, the electronic device may further include a communication unit communicating with an external device.

In one embodiment, a vehicle including the electronic device can be provided.

According to an embodiment of the present disclosure, the method includes: validating a registration request of a source application for communicating with a destination application; Determining, according to a result of the checking, a port for communicating with the destination application; Sending a communication request to the destination application through the determined port; And causing the source application to connect with the destination application based on the communication request.

According to an embodiment of the present disclosure, an electronic device and a method of operating the electronic device may include an electronic device and a method for implementing an in-vehicle network. The method includes registering a source application with a network through a registration request and an AUTOSAR library, determining the port number for communicating with the destination application as the registration request is approved, Sending a communication request to the destination application via the one or more low-level RINA DIFs until the communication request is processed by the source application's Recursive Inter-Network Architecture (RINA) library and the communication request reaches the Ethernet layer. Delivering recursively through Distributed IPC Facilities; Passing through the one or more Ethernet switches until the communication request reaches a destination Electric Control Unit (ECU); And recursively forwarding the communication request to one or more higher level RINA DIFs until the received communication request reaches the destination application's AUTOSAR library and the destination application.

According to one embodiment of the present disclosure, the system may include a source application in the first electronic control unit and a destination application in the second electronic control unit from the plurality of electronic control units. In addition, the source application may include a corresponding AUTOSAR architecture in communication with the destination application. In addition, the system may include one or more corresponding distributed interprocess communication facilities for each of the plurality of electronic control units, one or more of the Ethernet layers connecting the one or more automotive components and the plurality of electronic control units to implement the RINA protocol. It may include an Ethernet switch and a central switch connecting one or more Ethernet switches.

Embodiments of the present disclosure simplify the topology of the entire network to integrate the network into a single network, thereby enabling more efficient use of the high bandwidth provided by the physical layer, such as Ethernet.

In addition, embodiments of the present disclosure allow electronic devices to easily exchange information with other electronic devices.

In addition, embodiments of the present disclosure may use security inherent in network design, rather than specific security mechanisms, to enhance security using dynamically assigned ports and addresses without the need for known ports or public addresses.

In addition, embodiments of the present disclosure, by implementing a network with a simple wiring using a physical layer, such as Ethernet can reduce the economic cost in communication between devices.

Other features and advantages of the disclosure will be apparent from the following detailed description and the accompanying drawings.

1 is a block diagram illustrating a system in which a source application and a destination application communicate within a network according to an embodiment.
2 is a flowchart of a method for a source application to communicate with a destination application according to one embodiment.
3 is a flowchart of a method for communicating between applications in a network operating based on a recursive network architecture, according to one embodiment.
4 is a flowchart illustrating a method in which a first electronic control unit ECU communicates with a second electronic control unit ECU according to an embodiment.
FIG. 5 is a block diagram illustrating a Recursive Internetwork Architecture (RINA) structure according to an embodiment. FIG.
6 is a block diagram illustrating a network topology in an in-vehicle network, according to an exemplary embodiment.
7 is a block diagram illustrating a structure of a communication stack according to an embodiment.
8 is a block diagram of an electronic device according to an embodiment.

Hereinafter, with reference to the accompanying drawings will be described in detail to be easily carried out by those of ordinary skill in the art. However, the embodiments may be implemented in various forms and are not limited to the embodiments described herein. In the drawings, parts irrelevant to the description are omitted for clarity of description, and like reference numerals designate like parts throughout the specification.

The terms used in the present disclosure selected general terms widely used as far as possible in consideration of functions in the present disclosure, but may vary according to the intention or precedent of a person skilled in the art, the emergence of new technologies, and the like. In addition, in certain cases, there is also a term arbitrarily selected by the applicant, in which case the meaning will be described in detail in the description of the corresponding disclosure. Therefore, the terms used in the present disclosure should be defined based on the meanings of the terms and the contents throughout the present disclosure, rather than simply the names of the terms.

Singular expressions include plural expressions unless the context clearly indicates otherwise. The terms "comprise" or "have" are intended to indicate that a feature, number, step, action, component, part, or combination thereof exists, and that one or more other features or numbers, steps, actions, configurations It should be understood that it does not preclude the presence or possibility of addition of elements, parts or combinations thereof. In particular, numbers should not be construed as limiting the embodiments by the numbers described, as examples for ease of understanding.

An expression such as "at least one" modifies the entire list of components and does not individually qualify the components of the list. For example, "at least one of A, B, and C" means only A, only B, only C, both A and B, both B and C, both A and C, all of A and B and C, or a combination thereof. Point to.

Terms including ordinal numbers such as first and second may be used to describe various components, but the components are not limited by the terms. The terms are only used to distinguish one component from another. For example, without departing from the scope of the present disclosure, the first component may be referred to as a second component, and similarly, the second component may also be referred to as a first component. The term and / or includes any one of a plurality of related items or a combination of a plurality of related items.

Also, as used herein, the term "part" means a hardware component such as software, FPGA, or ASIC, and "part" plays certain roles. However, "part" is not meant to be limited to software or hardware. The “unit” may be configured to be in an addressable storage medium and may be configured to play one or more processors. Thus, as an example, a "part" refers to components such as software components, object-oriented software components, class components, and task components, processes, functions, properties, procedures, Subroutines, segments of program code, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays and variables. The functionality provided within the components and "parts" may be combined into a smaller number of components and "parts" or further separated into additional components and "parts".

Also, in the present disclosure, AUTOSAR is short for "Automotive Open System Architecture" and refers to a standardized open software architecture of an automotive electronic control unit (ECU). The standard refers to different manufacturers. Was developed through the collaboration of automotive stakeholders to build an architecture that is compatible and extensible with automotive and other suppliers' electronic components, through the use of the AUTOSAR Application Programming Interface (API). Can interoperate.

Also in the present disclosure, inter-process communication (IPC) refers to communication in a manner in which processes communicate with each other and the processes synchronize their operations. In interprocess communication, when more than one process is running at the same time, shared memory can be used that can share resources. For example, the first process is running and the running result can be stored in the shared memory, and the second process can access the shared memory to use the running result of the first process. In interprocess communication, a message may be delivered in which one process establishes a communication link with another process. The message is passed between communication links, and the header of the message can be used to determine the recipient and the process that the recipient will perform.

In addition, in the present disclosure, Distributed IPC Facility (DIF) refers to a layer composed of IPC processes within a network system. The DIF layers can execute the same processes with different policies or functions for the higher application process. At the same time, the upper application process may be a DIF for a broader scope of services. Two applications on different end hosts can communicate via DIF.

In addition, in the present disclosure, Recursive Internetwork Architecture (RINA) refers to a network architecture based on interprocess communication. In RINA, DIFs are recursed so that DIFs can provide IPC services to each other. Unlike traditional network architectures that follow the OSI model, not all DIF layers in RINA have specific functions, but instead can perform the same function across different scopes and underlying media. However, the number of hierarchies may not be fixed. The DIF layer can be stacked as needed and can vary depending on the process or application required.

In addition, in the present disclosure, an electric control unit (ECU) of a vehicle may control one or more electrical systems or subsystems of the vehicle. The ECU may be embedded in an automotive system. In one embodiment, the ECU is a door control unit (DCU), an engine control unit (ECU), a seat control unit, a speed control unit ( speed control unit (SCU), computer communication control unit (TCU), transmission control unit, brake control module (BCM), power train control module (PCM) and battery operation system (battery management system, BMS), but is not limited thereto. For example, an electronic control unit of a device that can be connected with a vehicle or an automobile system of the vehicle can also be included in the ECU.

Also, in the present disclosure, Ethernet is a technical standard utilized in LAN, WAN, and MAN. Ethernet can define signaling and routing at the physical layer of the OSI model, and media access control (MAC) packets and protocol formats at the data link layer.

Hereinafter, exemplary embodiments of the present disclosure will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present disclosure. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention. The specific implementations described in this disclosure are only one embodiment and in no way limit the scope of the disclosure. For brevity of description, descriptions of conventional electronic configurations, control systems, software, and other functional aspects of the systems may be omitted.

Hereinafter, the present disclosure will be described in detail with reference to the accompanying drawings.

1 is a block diagram illustrating a system in which a source application and a destination application in a network communicate, according to an embodiment.

Referring to FIG. 1, a system includes a first ECU 100 including a library 104 with embedded protocol 106 and a source application 102, a first including an embedded library and a destination application 122 with a protocol. At the ECU 120, at least one higher level DIF 140, 150, at least one lower level DIF 161, 163, 165, 167, 169, at least one router 192, 194, 196, 198 and the Ethernet layer. One or more Ethernet switches 181, 182, 183, 184, 185, and 186. Although the communication layer is represented by DIF and the physical layer is represented by the Ethernet layer, it may be a communication layer or a physical layer other than DIF or Ethernet. Also, the routers 192, 194, 196, and 198 may be at least one of the boundary routers 192, 194, and 198, the central router 196, the internal router, the designated router, and the backup designated router, but are not limited thereto. .

The first ECU 100 and the second ECU 120 may be referred to as a source ECU and a destination ECU, respectively. In one embodiment, the first ECU 100 and the second ECU 120 may be units constituting the vehicle, but may also be units connected to the vehicle. The first ECU 100 may be a unit for assisting the driver of the vehicle. For example, the first ECU 100 may be an advanced driver assistance system (ADAS) ECU, but is not limited thereto, and may be a mobile device, a remote device, or the like, connected to a vehicle to control the vehicle. have. In one embodiment, the second ECU 120 may be a unit other than the first ECU 100. For example, the second ECU 120 may be a camera ECU, but is not limited thereto, and includes a sensor ECU, an airbag ECU, an engine ECU, a powertrain ECU, a transmission ECU, a battery management ECU, and a bottom surface. It may be a system ECU, a driving safety system ECU, an information crab ECU, or an HV / EV system ECU.

In one embodiment, source application 102 may be an application to assist a driver of a vehicle. For example, source application 102 may be an advanced driver assistance system (ADAS) application. In one embodiment, destination application 122 may be an application driven in a vehicle in addition to the driver assistance system application. For example, destination application 122 may be, but is not limited to, a camera application, a sensor application, a door control application, a communication application, a dashboard application, a gear application.

In one embodiment, the library 104 of the source application 102 may be an AUTOSAR library 104, and the protocol 106 embedded in the AUTOSAR library 104 may be a RINA protocol 106. The library of the destination application 122 may be an AUTOSAR library, and the protocol embedded in the AUTOSAR library of the destination application 122 may be a RINA protocol.

According to one embodiment, the higher level DIF 140, 150 may be a DIF in direct communication with the applications 102, 122. On the other hand, the lower level DIF (161, 163, 165, 167, 169) is the DIF that communicates with the higher level DIF (140, 150) or Ethernet switch (181, 182, 183, 184, 185, 186) of the Ethernet layer. Can be. Processes for the higher level DIF 140, 150 may be specified based on the application of the ECU in communication with the higher level DIF 140, 150, for the lower level DIF 161, 163, 165, 167, 169. Processes may be simple processes, such as passing and blocking messages, but are not limited to such.

In one embodiment, the lower level DIFs 161, 163, 165, 167, 169 may serve as firewalls to forward or block messages going to or coming from the Ethernet layer and higher level DIF. Lower-level DIFs 161, 163, 165, 167, and 169 act as firewalls to filter the connection between Ethernet and DIF and intercept data coming into or coming from an application. The filtering process can be done on a per process or per port basis.

According to one embodiment, connecting all the DIFs together may be the central DIF 155 in the central router 196. The backbone DIF 155 may enable DIFs in different parts of the network to communicate with each other. The backbone router 196 may be located within the backbone switch that physically connects all the ECUs together in turn via Ethernet switches 181, 182, 183, 184, 185, 186. The Ethernet switch can be connected to a plurality of ECUs. For example, in an in-vehicle network, the ECU and lighting controls of the Advanced Driver Assistance System (ADAS) can be connected to an instrument cluster Ethernet switch.

According to one embodiment, an address may be embedded in each DIF. In order for two applications to communicate, both applications may have a common DIF. If there is no common DIF between the two applications, the two applications can either connect to an existing DIF to have a common DIF, or create a new DIF layer. According to one embodiment, applications that do not have a common DIF cannot communicate with each other, so unlike the existing architecture in which all applications had to know and connect to each address in order to communicate with each other, one of the present disclosure In embodiments, external access may be restricted.

According to one embodiment, each DIF may be a secure container capable of implementing its own authentication, encryption, and trust mechanisms. Applications can be registered with a common DIF to communicate with each other. Applications registered with the common DIF may communicate with that destination application using the name of the destination application with which to communicate. Unlike architectures that communicate using an application's network address, in one embodiment a port number may be assigned to an application, for example, a source application that wants to communicate with a destination application. Port numbers can be dynamically assigned. According to one embodiment, since the address of the application is not exposed to the lower layer, the vulnerability to the targeted attack can be reduced. In one embodiment, authentication credentials may be used to communicate with the destination application. For example, for additional security, the name of the application can be encrypted and sent with the authentication key.

According to one embodiment, security inherent in network design, rather than specific security mechanisms, can be used to enhance security using dynamically assigned ports and addresses without the need for known ports or public addresses.

2 is a flowchart of a method for a source application to communicate with a destination application according to one embodiment.

The method for the source application to communicate with the destination application may be performed by the electronic device. The electronic device may be or be part of the system of FIG. 1. For example, the electronic device may be the first ECU 100 of the system of FIG. 1, but is not limited thereto. According to one embodiment, the destination application may be an application operating within the same electronic device as the source application, or may be an application operating on a separate electronic device. For example, referring to FIG. 1, the source application may operate on the first ECU 100 and the destination application may operate on the second ECU 120.

At 210, the electronic device may validate the registration request of the source application. According to an embodiment, if there is a registration request, the electronic device may register the source application with the network through the first library. The network in which the source application is registered may be a DIF connected to both the first ECU and the second ECU, but is not limited thereto. In addition, the first library used to register the source application to the network may be, but is not limited to, an AUTOSAR library of the first ECU.

In one embodiment, the registration request may include at least one of a name of the destination application and a desired quality of service (QoS). In addition, the electronic device may transmit the registration request from the first library of the source application to the second library and check the validity of the registration request received by the second library of the source application.

According to an embodiment, the second library for validating the received registration request may be, but is not limited to, an RINA library having an RINA protocol. The first ECU may communicate with the external device through an operation such as registering a source application to the network through the first library, and the first ECU may share a common DIF through an operation such as checking a registration request through the second library. Communicate with a destination application of a second ECU having a.

The first library and the second library may be classified according to functions performed by the corresponding library, but one library may serve as both the first library and the second library. The roles of each of the first library and the second library may be performed by a plurality of sub libraries.

According to one embodiment, the first library of the source application may be an AUTOSAR library and the second library of the source application may be a RINA library. If there is a registration request, the electronic device can register the source application with the network via the AUTOSAR library. Once the source application is registered with the network, the electronic device can send a registration request from the AUTOSAR library to the RINA library. The RINA library can validate the registration request received. If the registration request is not valid, the method may end at 210.

At 220, the electronic device may determine a port for the source application to communicate with the destination application according to the validation result of the registration request at 210. The electronic device can also use the dynamic routing table to dynamically assign port numbers in determining the ports. If it is determined that the registration request is valid, the second library of the source application may return a port identifier of the source application.

For example, if it is determined that the registration request is valid, the RINA library, which is the second library of the source application, may return a port number obtained by dynamically allocating a port of the source application. Using the returned port number, the electronic device may proceed to 230.

At 230, the electronic device may send a communication request to the destination application through the determined port. The communication request may be sent from the source application to the destination application via the port determined at 220 and the first library of source applications. In addition, the second library of the source application may receive a communication request from the first library of the source application and recursively send to one or more lower level DIFs until the communication request reaches the physical layer. In addition, the electronic device may recursively transmit the communication request to one or more intermediate switches until the communication request reaching the physical layer reaches the destination ECU. Accordingly, the communication request may be sent to the destination application and the first library of the destination application.

The first library of the destination application may be an AUTOSAR library corresponding to the first library of the source application, but is not limited thereto. The second library of the destination application may be, but is not limited to, a RINA library corresponding to the second library of the source application.

In one embodiment, the first library and the second library of the destination application may be embedded with the same protocol as the first library and the second library of the source application, respectively.

At 240, the electronic device may cause the source application to connect with the destination application based on the communication request. As the source application connects to the destination application, the source application can communicate with the destination application.

3 is a flowchart of a method for communicating between applications within a network operating based on a recursive network architecture, according to one embodiment.

At 310, the electronic device may register the source application with the network through the first library. For example, the electronic device may be an in-vehicle device and the first library may be an AUTOSAR library. In this case, the electronic device may register the source application with the network through the AUTOSAR library based on the registration request. Thus, mutual information exchange with other automotive components that meet the AUTOSAR standard may be possible. In addition, because Ethernet hardware is the backbone Ethernet, it can support RINA networks. For elements without this hardware configuration (eg legacy automotive components), other gateways that follow the AUTOSAR standard can be used to connect to the RINA network.

For example, for functions such as lane departure warnings, the ADAS system may rely heavily on input from the vehicle's imaging system. In this case, the ADAS source application must be able to communicate with the camera application within the automotive system. As a process for the source application ADAS to communicate with the camera application that is the destination application, ADAS may be first registered in the AUTOSAR library by a registration request through the AUTOSAR Runtime Environment (RTE) to register with the network. The registration request may include the name of the destination application and optionally a quality of service (QoS).

The electronic device may transmit a registration request from the first library to the second library at 320. For example, the electronic device may send a registration request from the AUTOSAR library of the source application to the RINA library of the source application.

At 330, the electronic device may check whether the registration request is valid. According to an embodiment, the second library of the source application may check whether the registration request is valid and register the source application with the communication layer. If it is determined that the validity is invalid, the electronic device may terminate the communication process. If it is determined that the test result is valid, the electronic device may continue the process for the source application to communicate with the destination application. For example, the RINA library that receives the registration request from the AUTOSAR library can validate the registration request and register the source application with the RINA DIF according to the check result.

At 340, the electronic device may determine a port of the source application for communicating with the destination application and a port identifier corresponding to the port. According to one embodiment, the electronic device can dynamically allocate a port of the source application for communicating with the destination application. In addition, determination of a port identifier, such as a port number, can be determined using a dynamic routing table. Thus, the system may only need the name of the destination application to assign an empty port to the application. Accordingly, by using identifiers for dynamically assigned ports and ports, the need for known ports and public addresses can be eliminated to compensate for network attacks from the outside. In addition, the system can use smaller routing tables, resulting in lower routing overhead and improved network performance. According to an embodiment, the port identifier may be a port number, a port name, a port address, and the like, but is not limited thereto.

For example, in an automotive system the application of the engine control unit can communicate with almost all other applications for driving safety and road safety. Under the existing network architecture, the application received data from only one port. This can cause delays in the data and affect the processing, leading to potential risks. With RINA, the flow of data can be assigned to all ports. This may also eliminate the need for well-known ports that are commonly targeted to attack networks and the need for commonly-addressed public addressing to attack networks.

The electronic device may transmit the port identifier to the source application at 350. Also, at 360, the electronic device can send a communication request to the destination application. According to an embodiment, the source application may transmit a communication request to the destination application through a port corresponding to the received port identifier.

The electronic device may recursively transmit the communication request to the lower level communication layer until the communication request reaches the physical layer at 370. According to an embodiment, the electronic device may recursively transmit a communication request received by the second library of the source application to at least one communication layer until reaching a physical layer such as an Ethernet layer. For example, communication requests can be sent recursively to one or more lower level RINA DIFs via the RINA library of the source application until the communication request reaches the Ethernet layer.

The electronic device may recursively transmit the communication request to the network switch until the communication request reaches the destination electronic control unit at 380. For example, an intermediate Ethernet switch acting as a RINA router from the Ethernet layer can forward the request until the request reaches the destination ECU.

The electronic device may recursively transmit the communication request to the higher level communication layer until the communication request reaches the destination application at 390. For example, the RINA library of the destination ECU can recursively forward the request to the higher level RINA DIF associated with the destination ECU until the request reaches the AUTOSAR library that forwards the request to the destination application. The AUTOSAR library can forward requests to the destination application.

4 is a flowchart illustrating a method in which a first ECU communicates with a second ECU, according to an embodiment.

At 411, the first ECU 410 may register the source application with the network through the first library of source applications based on the registration request to communicate with the second ECU 490. In operation 413, the first ECU may transmit a registration request from the first library to the second library. According to an embodiment, at 415, the second library of the source application may determine the validity of the received registration request. If the second library determines that the registration request is valid, the first ECU 410 may dynamically allocate a port. Accordingly, at 417, the second library may determine a port identifier of the dynamically allocated port and return it to the source application. In operation 422, the source application may receive the port identifier and transmit a communication request to communicate with the destination application of the second ECU 490 through a port corresponding to the port identifier.

According to one embodiment, the communication request sent from the source application of the first ECU 410 to the destination application of the second ECU 490 may be a low level DIF 430, an Ethernet layer 450, and a high level DIF 470. May pass through at least one of. According to one embodiment, at 424, the first ECU 410 may recursively forward the communication request to the lower level DIF 430. Further, at 435, the communication request may be forwarded until it reaches the Ethernet layer 450. In one embodiment, the one or more Ethernet layers 450 are Ethernet switches, where the name of the destination application of the second ECU 490 may be encrypted and transmitted. In addition, at 455, the communication request may be forwarded until it reaches the intermediate Ethernet switch. Further, at 472, the communication request may be sent from the higher level DIF 470 to the destination application of the second ECU 490. The second ECU may access the source application of the first ECU 410 through the received communication request.

For example, the first ECU may be an Advanced Driver Assistance System (ADAS) and the second ECU may be an ECU of a camera system. According to one embodiment, an application of ADAS may run on a RINA network. ADAS can be a system that assists drivers to improve vehicle safety and road safety while driving. ADAS systems may use automotive systems such as electronic control units (ECUs) and brake management systems, imaging systems, and engine control units to perform certain functions such as electronic stability control, lane departure warning, cruise control, and traction control. It is not limited. For example, for functions such as lane departure warnings, ADAS may rely heavily on input from the vehicle's imaging system. In this case, the ADAS source application must be able to communicate with the camera application within the automotive system. The source application can be registered with the network in order for the ADAS source application to communicate with the camera application that is the destination application. If there is a registration request, the ADAS source application can be registered first with the AUTOSAR library through the AUTOSAR Runtime Environment (RTE) in order to be registered in the network. According to one embodiment, the registration request may include the name of the destination application and optionally the quality of service (QoS) required. According to an embodiment, the AUTOSAR library may send a registration request to the RINA library. In addition, the RINA library according to an embodiment may check the validity of the registration request, register the source application with the corresponding RINA DIF, and return the port number of the source application corresponding to the port identifier to communicate with the destination application. . The source application can also send a communication request to the destination application using the returned port number. The AUTOSAR library sends a communication request to the RINA library and the RINA library can recursively send the communication request to one or more lower level RINA DIF 430 until the communication request reaches the Ethernet layer 450. An intermediate Ethernet switch acting as RINA routers from the Ethernet layer 450 may carry the request until the request reaches the destination ECU 490. The RINA library of the destination ECU 490 recursively sends the request to one or more higher level RINA DIF 470 until the request reaches the AUTOSAR library, and the AUTOSAR library of the second ECU 490 sends the request to the destination application. Can be sent to.

5 is a block diagram illustrating a Recursive Internetwork Architecture (RINA) structure according to an embodiment.

Referring to FIG. 5, an application 512 includes an RINA network that includes one or more DIFs 540, 550, 562, 564, 566, and 568 to communicate with each other over another application 522 and a Recursive Internetwork Architecture (RINA) network. Can be used. According to an embodiment, the RINA is one of the inter-process communication models, and may be a structure including a single repetition layer called a Distributed IPC Facility or DIF. The designer of the network can also design the network by repeating the DIF as necessary. Unlike conventional network architectures, where layers are modular, RINA networks can use any number of DIFs that perform the same function at different scopes. According to an embodiment, the node of the RINA may be configured as a host 510, 520, border routers 532, 536, or internal router 534, but is not limited thereto.

For example, the higher level DIF 540 may be directly connected to two hosts 510 and 520. In addition, the lower level DIFs 562, 564, 566, and 568 may be connected with a host and a router or between a plurality of routers. Low-level DIFs 562, 564, 566, and 568 may serve as firewalls to enhance security in communications on RINA networks.

6 is a block diagram illustrating a network topology in an in-vehicle network, according to an embodiment.

Referring to FIG. 6, the in-vehicle network topology includes a backbone switch 320, one or more door control switches 622, 634, a front chassis switch 626, a rear chassis switch 630, an instrument panel switch 624. , At least one of a camera switch 632 and one or more electronic control units 600, 602, 604, 640. The ECUs 600, 604, 640 may be connected to one or more switches, and the ECU 602 may be connected to another ECU 604. In addition, the central switch 610 may be a central component that connects the network into one. Accordingly, the central switch 610 may facilitate routing and management of the network.

For example, a situation may be considered in which the ADAS ECU 600 is in communication with the camera ECU 640. The message may first pass through switches such as instrument panel switch 624 and front chassis switch 626. It may also be transferred to the camera switch 636 via the central switch 610. According to an embodiment, a component that does not have the function of Ethernet may be connected to a network through a gateway if it complies with the AUTOSAR standard. Thus, the topology can build an integrated network with Ethernet as the primary physical medium. Accordingly, costs can be reduced by minimizing the use of gateways and other expensive subnetwork implementations. It also allows other compatible ECUs to be easily connected to the network with minimal setup and configuration.

According to one embodiment, by simplifying the topology of the entire network to integrate the network into a single network, it is possible to more effectively utilize the high bandwidth provided by the physical layer, such as Ethernet.

7 is a block diagram illustrating a structure of a communication stack according to an embodiment.

Referring to FIG. 7, a communication stack according to an embodiment may include a microcontroller abstraction layer (MCAL) 780, a basic software layer 760, and a run-time. environment (RTE) 740 and application layer 720. However, not all of the configurations shown in FIG. 7 are essential components of the communication stack. The communication stack may be implemented by more components than the components shown in FIG. 7, and the communication stack may be implemented by fewer components than the components shown in FIG. 7.

According to one embodiment, the basic software layer 760 includes a system service, I / O driver, memory service, memory hardware abstraction layer, memory driver, communication service, communication hardware layer, communication driver, I / O hardware layer, and the like. It may be, but is not limited thereto. According to one embodiment, the protocol may be integrated into the communication stack 762. This integration allows applications and systems to communicate with the network. For example, the RINA protocol is integrated into the communications stack of the AUTOSAR architecture and allows AUTOSAR applications and systems to communicate with the RINA network. Also, even if the application's Ethernet cannot be connected, it can communicate with other applications while running in AUTOSAR.

8 is a block diagram of an electronic device, according to one embodiment.

Electronic devices include automobiles, vehicle components, vehicle electronic control units (ECUs), smartphones, tablet PCs, PCs, smart TVs, mobile phones, personal digital assistants (PDAs), laptops, media players, micro servers, global positioning systems (GPS). system) devices, e-book terminals, digital broadcasting terminals, navigation, kiosks, MP3 players, digital cameras, home appliances, and other mobile or non-mobile computing devices, but is not limited thereto. In addition, the device 900 may be a wearable device such as a watch, glasses, a hair band and a ring having a communication function and a data processing function.

Referring to FIG. 8, the electronic device 800 may include a processor 820, a communication unit 840, and a memory 860. However, not all of the configurations shown in FIG. 8 are essential components of the electronic device 800. The electronic device 800 may be implemented by more components than the components shown in FIG. 8, and the electronic device 800 may be implemented by fewer components than the components shown in FIG. 8.

In one embodiment, the processor 820 controls the overall operation of the electronic device 800, and may include at least one or more processors such as a CPU, a GPU, and the like. The processor 820 may control other components included in the electronic device 800 to perform an operation for operating the electronic device 800. For example, the processor 820 may execute a program stored in the memory 860, read a stored file, or store a new file. In one embodiment, the processor 820 may perform an operation for operating the electronic device 800 by executing a program stored in the memory 860. For example, the processor 820 validates the registration request of the source application for communicating with the destination application, determines a port for communicating with the destination application according to the inspection result, and communicates to the destination application through the determined port. Send a request and allow the source application to connect with the destination application based on the communication request.

In one embodiment, the communicator 840 may wire or wirelessly communicate with the electronic device 800. In one embodiment, the electronic device 800 may communicate with other electronic devices via wire or wirelessly via the communicator 840. For example, via the communication unit 840, applications of the in-vehicle ADAS device may communicate with applications of the in-vehicle camera device to receive image data from the camera device. In addition, the communication unit 840 may include one or more components for communicating with an external server (eg, an SNS server, a cloud server, a content providing server, etc.) and other external devices. For example, the communication unit 840 may include a short range communication unit, a mobile communication unit, and a broadcast receiving unit. According to an embodiment, the communication unit 840 may receive data from an external device or server and provide the received data to the processor 820.

In one embodiment, the memory 860 may store various data, programs or applications for driving and controlling the electronic device 800. The program stored in memory 860 may include one or more instructions. A program (one or more instructions) or application stored in memory 860 may be executed by processor 820. In addition, the memory 860 may store data input to or output from the electronic device 800. The processor 820 may access and use data stored in the memory 860 or store new data in the memory 860.

One embodiment may also be embodied in the form of a recording medium containing computer readable and computer executable instructions, such as program modules executed by a computer. Computer readable media can be any available media that can be accessed by a computer and includes both volatile and nonvolatile media, removable and non-removable media. In addition, the computer readable medium may include a computer storage medium. Computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.

The disclosed embodiments may be implemented as S / W programs that include instructions stored in computer-readable storage media.

The computer is a device capable of calling stored instructions from a storage medium and operating according to the disclosed embodiments according to the called instructions, and may include an electronic device according to the disclosed embodiments.

The computer readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-temporary' means that the storage medium does not include a signal and is tangible, but does not distinguish that data is stored semi-permanently or temporarily on the storage medium.

In addition, the control method according to the disclosed embodiments may be provided included in a computer program product. The computer program product may be traded between the seller and the buyer as a product.

The computer program product may include a S / W program and a computer readable storage medium storing the S / W program. For example, a computer program product may include a product (eg, a downloadable app) in the form of a S / W program distributed electronically through a device manufacturer or an electronic market (eg, Google Play Store, App Store). . For electronic distribution, at least a part of the S / W program may be stored in a storage medium or temporarily generated. In this case, the storage medium may be a server of a manufacturer, a server of an electronic market, or a storage medium of a relay server that temporarily stores a SW program.

The computer program product may include a storage medium of a server or a storage medium of a device in a system consisting of a server and a device. Or, if there is a third device (eg, a smartphone) that is in communication with the server or device, the computer program product may include a storage medium of the third device. Alternatively, the computer program product may include the S / W program itself transmitted from the server to the device or the third apparatus, or transmitted from the third apparatus to the device.

In this case, one of the server, the device and the third apparatus may execute the computer program product to perform the method according to the disclosed embodiments. Alternatively, two or more of the server, the device and the third apparatus may execute a computer program product to distribute and perform the method in accordance with the disclosed embodiments.

For example, a server (eg, a cloud server or artificial intelligence server, etc.) may execute a computer program product stored on the server to control a device in communication with the server to perform the method according to the disclosed embodiments.

As another example, the third device may execute a computer program product to control the device in communication with the third device to perform the method according to the disclosed embodiments. When the third device executes the computer program product, the third device may download the computer program product from the server and execute the downloaded computer program product. Alternatively, the third apparatus may execute the provided computer program product in a preloaded state to perform the method according to the disclosed embodiments.

In addition, in the present disclosure, “unit” may be a hardware component such as a processor or a circuit, and / or a software component executed by a hardware configuration such as a processor.

The foregoing description of the disclosure is provided by way of illustration, and it will be understood by those skilled in the art that the present disclosure may be easily modified into other specific forms without changing the technical spirit or essential features of the present disclosure. will be. Therefore, it should be understood that the embodiments described above are exemplary in all respects and not restrictive. For example, each component described as a single type may be implemented in a distributed manner, and similarly, components described as distributed may be implemented in a combined form.

The scope of the present disclosure is indicated by the appended claims rather than the detailed description, and all changes or modifications derived from the meaning and scope of the claims and their equivalents should be construed as being included in the scope of the present disclosure. do.

Claims (20)

Memory for storing one or more instructions; And
At least one processor executing the one or more instructions,
The at least one processor,
Validate the registration request of the source application to communicate with the destination application,
According to the result of the check, determine a port for communicating with the destination application,
Send a communication request to the destination application through the determined port;
And cause the source application to connect with the destination application based on the communication request. The electronic device of claim 1, wherein the registration request includes at least one of a name of the destination application and a desired quality of services. The processor of claim 1, wherein the at least one processor comprises:
And register the source application with a network via the first library of source applications based on the registration request. The processor of claim 1, wherein the at least one processor comprises:
And recursively forward the communication request to at least one communication stack until the communication request reaches a physical layer. The processor of claim 1, wherein the at least one processor comprises:
And recursively transmit the communication request to one or more Ethernet switches until the communication request reaches a processor controlling the destination application. The processor of claim 1, wherein the at least one processor comprises:
And further determine the port dynamically. The processor of claim 6, wherein the at least one processor comprises:
Further determine a port identifier indicative of the determined port,
The port identifier indicating the determined port is,
And a port number dynamically assigned by the second library of the source application. The processor of claim 1, wherein the at least one processor comprises:
And transmit the registration request from the first library of the source application to the second library of the source application. The method of claim 1,
And the registration request includes an encrypted name and an authentication key of the destination application. The method of claim 1,
And a communication unit for communicating with an external device. Validating a registration request of a source application for communicating with a destination application;
Determining, according to a result of the checking, a port for communicating with the destination application;
Sending a communication request to the destination application through the determined port; And
Causing the source application to connect with the destination application based on the communication request. 12. The method of claim 11, wherein the registration request includes at least one of a name of the destination application and a desired QoS. 12. The method of claim 11, further comprising registering the source application with a network through the first library of source applications based on the registration request. 12. The method of claim 11, wherein the step of transmitting comprises: recursively forwarding the communication request to at least one communication stack until the communication request reaches a physical layer. How to include. The method of claim 11, wherein the transmitting step,
Recursively sending to the one or more Ethernet switches until the communication request reaches a processor controlling the destination application. The method of claim 11,
Dynamically determining the port. The method of claim 16,
Determining a port identifier indicating the determined port;
The port identifier indicating the determined port is,
And a port number dynamically assigned by the second library of the source application. The method of claim 11,
The registration request includes an encrypted name and an authentication key of the destination application. The method of claim 11,
The registration request further comprising transferring from a first library of the source application to a second library of the source application. A computer-readable recording medium storing one or more programs,
The one or more programs, when executed by one or more processors of the electronic device, cause the electronic device to:
Validate the registration request from the source application to communicate with the destination application,
According to the result of the check, determine a port for communicating with the destination application,
Send a communication request to the destination application through the determined port,
And computer-readable instructions including instructions for causing the source application to connect with the destination application based on the communication request.

Images