Vehicle signals communicated using a POSIX-based directory interface

Abstract

To provide vehicle signals communicated using a POSIX-based directory interface. [Solution] A method for acquiring vehicle signal data. The method includes: reading a vehicle signal catalog by a communication service layer application running on a computer system, wherein the catalog defines vehicle signals as full-path file names; receiving a request from a second application by the communication service layer application regarding the values ​​of vehicle signals, wherein the request identifies the vehicle signals as full-path file names; acquiring the values ​​of the vehicle signals by the communication service layer application; and returning the values ​​of the vehicle signals to the second application.

Description

Background Art

[0001] (Cross - reference to related applications) None

[0002] (Description of research and development by federal government funds) Not applicable

[0003] (Reference to microfiche appendix) Not applicable

[0004] Modern motor vehicles comprise a complex mixture of electromechanical and electronic systems. Many systems within the vehicle are at least partially controlled by electronic units that are in effect computers. Sensors report current condition values back to the electronic units, and the electronic units control the associated electromechanical systems based on the current condition values and inputs from other sources including those from the driver. Electronic units that control different electromechanical systems can report the current conditions of those systems to a central computer system (e.g., a telematics unit) via communication facilities such as a Controller Area Network (CAN) bus or other communication links. As motor vehicles become more complex and the number of electronic units within the vehicle increases, the communication within the motor vehicle between the various systems has become more complex.

Summary of the Invention

Means for Solving the Problems

[0005] In one embodiment, an in-vehicle electronic unit comprising a communication service layer is disclosed. The in-vehicle electronic unit comprises a processor; a memory, the non-transient portion of which stores a vehicle signal catalog defining vehicle signals as full-path filenames, each full-path filename comprising one or more containing directory names and a filename identifying a vehicle signal; an operating system (OS) stored in the non-transient portion of the memory, which, when executed by the processor, manages access to the memory and manages access to the processor; an application stored in the non-transient portion of the memory, which, when executed by the processor, processes at least one vehicle signal; and a communication service layer stored in the non-transient portion of the memory. When executed by the processor, the communication service layer reads the vehicle signal catalog from the non-transient portion of memory in accordance with the initialization of the communication service layer, receives a request from the application to access a vehicle signal, the request identifies the vehicle signal using the full path file name associated with the vehicle signal, retrieves a first value of the vehicle signal, maps the first value of the vehicle signal to a second value based on the normalized value definition for the vehicle signal in the catalog, and returns the second value to the application.

[0006] In another embodiment, a method is disclosed for obtaining vehicle signal data by an application running on a processor. The method includes: reading a vehicle signal catalog by a communications service layer application running on a computer system, wherein the vehicle signal catalog defines vehicle signals as full path filenames, each full path filename comprising one or more containing directory names and a filename that identifies a vehicle signal; receiving a request for a value of a vehicle signal from a second application running on the computer system, the communications service layer application receiving the request via a POSIX interface provided by the communications service layer application, the request identifying a vehicle signal as a full path filename; and the communications service layer application obtaining the value of the vehicle signal identified in the request and returning the value of the vehicle signal identified in the request to the second application.

[0007] In another embodiment, a method is disclosed for obtaining vehicle signal data by an application running on a processor. The method includes: reading a vehicle signal catalog by a communication service layer application running on a computer system, wherein the vehicle signal catalog defines vehicle signals as full path filenames, each full path filename comprising one or more containing directory names and a filename that identifies a vehicle signal; receiving a first request from a second application running on the computer system, the communication service layer application relating to a value of a vehicle signal, the first request identifying a vehicle signal as a full path filename; in response to receiving the first request, determining a first access definition for the vehicle signal based on the vehicle signal catalog, the communication service layer application determining, based on the first access definition for the vehicle signal and based on the identification of the second application, that the second application has read access permission for the vehicle signal identified in the first request; and the communication service layer application obtaining the value of the vehicle signal identified in the first request and returning the value of the vehicle signal identified in the first request to the second application.The method further includes the communication service layer application executing an access control list (ACL) command, the ACL command replacing a first access definition for a vehicle signal with a second access definition in a vehicle signal catalog; the communication service layer application receiving a second request from a second application for a value of a vehicle signal, the second request identifying the vehicle signal as a full path file name; the communication service layer application determining, in response to receiving the second request, a second access definition for the vehicle signal based on the vehicle signal catalog; the communication service layer application determining, based on the second access definition for the vehicle signal and based on the identification of the second application, that the second application does not have read access permission for the vehicle signal identified in the second request; and returning a rejection of the second request to the second application.

[0008] These and other features will be more clearly understood from the following detailed description, which will be considered in conjunction with the accompanying drawings and claims. The present invention provides, for example, the following items: (Item 1) An in-vehicle electronic unit equipped with a communication service layer, Processor and A memory wherein the non-transient portion of the memory stores a vehicle signal catalog that defines vehicle signals as full path filenames, and each full path filename comprises one or more containing directory names and a filename that identifies the vehicle signal. An operating system (OS) stored in the non-transient portion of the memory, wherein the OS, when executed by the processor, manages access to the memory and manages access to the processor. An application stored in the non-transient portion of the memory, wherein the application, when executed by the processor, processes at least one vehicle signal. A communication service layer stored in the non-transient portion of the memory, wherein the communication service layer is executed by the processor, In response to the initialization of the communication service layer, the vehicle signal catalog is read from the non-transient portion of the memory, The application receives a request to access a vehicle signal, the request identifies the vehicle signal using the full path file name associated with the vehicle signal, To obtain the first value of the aforementioned vehicle signal, Based on the definition of the normalized value for the vehicle signal in the aforementioned catalog, the first value of the vehicle signal is mapped to the second value, The second value described above is returned to the application. The communication service layer performs the following An in-vehicle electronic unit equipped with the following features. (Item 2) Before the communication service layer obtains the first value of the vehicle signal, Searching for access rights definitions related to the full path file name identified in the request within the vehicle signal catalog, The identification of the aforementioned application is compared with the access rights definition, Based on comparing the identification of the application with the access rights definition, it is determined that the application has permission to access the vehicle signal. The in-vehicle electronic unit described in the above items performs the following function. (Item 3) The aforementioned vehicle signal catalog is an in-vehicle electronic unit as described in any one of the above items, which defines the file name that defines the vehicle signal, as well as the access rights for the directory. (Item 4) The aforementioned OS is the QNX operating system, as described in any one of the above items for the in-vehicle electronic unit. (Item 5) The communication service layer is an in-vehicle electronic unit according to any one of the above items, which executes an access control list (ACL) command and adds a vehicle signal to the vehicle signal catalog. (Item 6) The in-vehicle electronic unit according to any one of the above items, wherein the communication service layer provides a POSIX interface, receives the request from the application via the POSIX interface, and returns the second value to the application via the POSIX interface. (Item 7) The in-vehicle electronic unit is one of the following: a telematics unit, an engine control unit, a body control unit, an airbag control unit, a cabin air control unit, a main road condition recognition unit, or a navigation unit, as described in any one of the above items. (Item 8) The in-vehicle electronic unit is an in-vehicle electronic unit as described in any one of the above items, located in a passenger car, pickup truck, sport utility vehicle (SUV), minivan, delivery van, delivery truck, camper van, moving van, moving truck, or towing vehicle for a semi-trailer. (Item 9) A method for acquiring vehicle signal data by an application running on a processor, A communication service layer application running on a computer system reads a vehicle signal catalog, wherein the vehicle signal catalog defines vehicle signals as full-path filenames, and each full-path filename comprises one or more containing directory names and a filename that identifies the vehicle signal. The communication service layer application receives a request regarding the value of a vehicle signal from a second application running on the computer system, the request is received via a POSIX interface provided by the communication service layer application, and the request identifies the vehicle signal as a full path file name. The communication service layer application obtains the value of the vehicle signal identified in the request, The value of the vehicle signal identified in the request is returned to the second application. Methods that include... (Item 10) The computer system is an electronic device unit located inside an automated vehicle, as described in any one of the above items. (Item 11) The computer system is a virtual execution platform, as described in any one of the above items. (Item 12) Based on the aforementioned vehicle signal catalog, the communication service layer application determines the access definition for the vehicle signal, Based on the access definition relating to the vehicle signal and the identification of the second application, the communication service layer application determines that the second application has read access permission relating to the vehicle signal identified in the request. It further includes, The method described in any one of the above items, wherein the full path file name in the vehicle signal catalog is compatible with the POSIX directory structure, and the access definition of the vehicle signal is defined in the vehicle signal catalog using POSIX file name access permissions. (Item 13) The method according to any one of the above items, wherein the vehicle signal catalog comprises metadata associated with the directory name and the file name. (Item 14) The metadata associated with the directory name and file name of the vehicle signal is defined in a separate file in the memory of the computer system, according to the method described in any one of the above items. (Item 15) A method for acquiring vehicle signal data by an application running on a processor, To read a vehicle signal catalog by a communication service layer application running on a computer system, wherein the vehicle signal catalog defines vehicle signals as full path file names, and each full path file name includes one or more included directory names and a file name for identifying the vehicle signal. To receive, by the communication service layer application from a second application running on the computer system, a first request regarding a value of a vehicle signal, wherein the first request identifies the vehicle signal as a full path file name. In response to receiving the first request, to determine, by the communication service layer application based on the vehicle signal catalog, a first access definition regarding the vehicle signal. To determine, by the communication service layer application, that the second application has read access permission regarding the vehicle signal identified in the first request based on the first access definition regarding the vehicle signal and on the identification of the second application. To obtain, by the communication service layer application, the value of the vehicle signal identified in the first request. To return, by the communication service layer application, the value of the vehicle signal identified in the first request to the second application. To execute, by the communication service layer application, an access control list (ACL) command, wherein the ACL command replaces the first access definition regarding the vehicle signal with a second access definition in the vehicle signal catalog. To receive, by the communication service layer application from the second application, a second request regarding a value of the vehicle signal, wherein the second request identifies the vehicle signal as a full path file name. In response to receiving the second request, to determine, by the communication service layer application based on the vehicle signal catalog, a second access definition regarding the vehicle signal. The communication service layer application determines that the second application does not have read access permission for the vehicle signal identified within the second request, based on the second access definition for the vehicle signal and based on the identification of the second application; returns a rejection of the second request to the second application; A method comprising: (Item 16) The method according to any one of the above items, wherein the communication service layer application runs on a QNX operating system installed on the computer system. (Item 17) The method according to any one of the above items, wherein the communication service layer application uses a QNX resource manager application programming interface (API) to obtain the value of the vehicle signal identified within the first request. (Item 18) The method according to any one of the above items, wherein the full path file name in the vehicle signal catalog is compatible with a POSIX directory structure, and the access definition of the vehicle signal is defined in the vehicle signal catalog using POSIX file name access permissions. (Item 19) When the communication service layer application is initialized, the method further includes providing a data format type to the communication service layer application, and the data format of the value of the vehicle signal identified within the first request returned to the second application is defined by the data format type provided during initialization of the communication service layer application. (Item 20) The method according to any one of the above items, wherein the data format type is one of a binary data type, a floating point data type, an ASCII data type, and an EBCDIC data type. (Abstract) A method for obtaining vehicle signal data. The method includes: reading a vehicle signal catalog by a communication service layer application running on a computer system, wherein the catalog defines vehicle signals as full-path filenames; receiving a request from a second application by the communication service layer application for the values ​​of vehicle signals, wherein the request identifies the vehicle signals as full-path filenames; obtaining the values ​​of the vehicle signals by the communication service layer application; and returning the values ​​of the vehicle signals to the second application. [Brief explanation of the drawing]

[0009] For a more complete understanding of this disclosure, the following brief description, which is considered in relation to the accompanying drawings and detailed description, where similar reference numbers represent similar parts, is referenced herein.

[0010] [Figure 1] Figure 1 is a block diagram of a system according to one embodiment of the present disclosure.

[0011] [Figure 2] Figure 2 is a block diagram of another system according to one embodiment of the present disclosure.

[0012] [Figure 3] Figure 3 is a flowchart of a method according to one embodiment of the present disclosure.

[0013] [Figure 4A] Figures 4A and 4B are flowcharts of another method according to one embodiment of the present disclosure. [Figure 4B] Figures 4A and 4B are flowcharts of another method according to one embodiment of the present disclosure.

[0014] [Figure 5] Figure 5 is a block diagram of a computer system according to one embodiment of the present disclosure. [Modes for carrying out the invention]

[0015] Detailed explanation First, it should be understood that one or more illustrative implementations of the embodiments are illustrated below, but the disclosed systems and methods can be implemented using any number of techniques, whether currently known or not. This disclosure should not be limited in any way to the illustrative implementations, drawings, and techniques illustrated below, but may be modified within the scope of the appended claims, along with the entire scope of their equivalents.

[0016] As the number of electronic units in automated vehicles increases, and the in-vehicle software running on these units becomes more sophisticated, providing access to vehicle signals and carefully securing such access has become a significant technical issue. In a narrow sense, vehicle signals refer to in-vehicle parameter values. Examples of vehicle signals according to this narrow definition include tire pressure values, engine revolutions per minute (RPM) values, gas tank fuel level values, passenger cabin ambient temperature values, outside temperature values, anti-lock brake activation status values, passenger front airbag activation status values, and others. In a broader definition, vehicle signals can refer to both in-vehicle parameter values ​​(e.g., read-only values ​​or states) and control commands to electronic units (e.g., values ​​or states written or commanded), such as commands to modulate the fuel-air mixture introduced into the engine combustion chamber, or commands to reduce the throttle position to maintain the cruising control vehicle speed setting. Much of the following description relates specifically to the first, narrower definition of vehicle signals, but it should be understood that many, if not all, of the benefits of the systems disclosed herein can be adapted for use with a broader definition of vehicle signals, which includes both vehicle parameter values ​​and control commands.

[0017] Currently, different in-vehicle electronic units define application programming interfaces (APIs) that other electronic units can use to access vehicle signals. These APIs may differ from one automobile model to another. For example, the API for accessing tire pressure in a Ford sedan automobile may differ from the API for accessing tire pressure in a Ford pickup truck. In some cases, APIs for accessing substantially identical vehicle signals across different vehicle models may differ significantly. This lack of commonality between APIs makes software reuse difficult and makes system integration more time-consuming, expensive, and error-prone. It is desirable that a common method of accessing vehicle signals can be relied upon by electronic units in an automobile, which would improve software reuse, save development costs, and streamline system integration efforts. This disclosure teaches a novel in-vehicle communication service layer that can be used by applications running on in-vehicle electronic units to access vehicle signals uniformly and reliably. The communication service layer can be implemented as software and / or firmware within the electronic unit, or on a computer system in a test / integration environment. Electronic equipment units are substantially similar to computer systems. Computer systems will be described further below.

[0018] In one embodiment, a vehicle signal is defined within the vehicle signal catalog as a full path filename. The full path filename consists of a root directory name followed by zero or more subdirectory names and ends with the filename. An exemplary full path filename identifying a vehicle signal may be / vehicle / cabin / HVAC / AmbientAirTemperature. In this embodiment, "vehicle" is the root directory, "cabin" is a first-level subdirectory subordinate to the "vehicle" root directory, "HVAC" is a second-level subdirectory subordinate to the "cabin" subdirectory, and "AmbientAirTemperature" is the filename. In this embodiment, the full path filename is represented using slash delimiters, but it should be noted that other delimiters such as dots, periods, commas, or colons may also be used. In one embodiment, the vehicle signal catalog conforms to or is compatible with the Vehicle Signaling Specification (VSS) document or model supported by the Connected Vehicle Systems Alliance (COVESA). In one embodiment, the vehicle signal catalog defines a directory tree structure which, during startup of the electronics unit or execution platform, is linked by the communication service layer to a mount point in a file system within the electronics unit or other execution platform. For example, the vehicle signal catalog may define signals such as / Vehicle / Body / Mirrors / Left / IsHeatOn, and the communication service layer may link or attach the directory tree structure containing / Vehicle / Body / Mirrors / Left / IsHeatOn to a specific point in a file system on the electronics unit, such as / dev / signal. In this case, the full path file name for this signal would then be / dev / signal / Vehicle / Body / Mirrors / Left / IsHeatOn.

[0019] In one embodiment, the full path filename conforms to the POSIX directory structure. The use of the POSIX directory structure can provide several benefits, including the ability for software developers to use well-known POSIX APIs such as OPEN, READ, WRITE, and CLOSE. The use of POSIX APIs allows software developers to use other tools and utilities that utilize the POSIX APIs. The use of the POSIX directory structure enables the use of well-known POSIX security permissions, which may be defined for each node of the full path filename and with respect to different electronic units and / or users that may attempt to access the filename (e.g., access the vehicle signal identified by the full path filename). Similarly, the use of the POSIX directory structure can enable the use of utilities that work in conjunction with the POSIX directory structure, such as POSIX-compatible utilities invoked from the command line, including the CD command (change directory), MK DIR command (create directory), CAT command (enumerate file contents), LS command (enumerate directory contents), and ECHO command. However, it should be understood that this disclosure is not limited to vehicle signals being defined based on the POSIX directory structure.

[0020] A signal catalog can define a set of permissions for a vehicle signal. For example, read permissions, write permissions, and execute permissions may be defined for a given vehicle signal, for each specific user, specific group, and for the whole world. Permissions for a given vehicle signal may also be defined using a mask, for example, a mask with nine fields, where a binary 1 value indicates that the user or group or the whole world has permission, and a binary 0 value indicates that the user or group or the whole world does not have permission.

[0021] A signal catalog can define the value type of a vehicle signal as a data representation type (e.g., binary value, floating-point value, Boolean value, string value, etc.). The signal catalog can also define units and valid value ranges for vehicle signals. For example, a tire pressure value may be associated with units of pounds per square inch (PSI) or kilopascals (kP). For example, a tire pressure value may be associated with a valid value range of 25 PSI to 40 PSI or 170 kP to 310 kP. It should be understood that in this exemplary range, a tire pressure may be physically outside this limit, but a tire pressure value outside this range may be considered abnormal or dangerous, or may trigger an alarm indication. The allowable mask, units, and valid value range of a vehicle signal are examples of metadata associated with filenames within the signal catalog. The signal catalog can also define metadata associated with each directory and / or subdirectory. Another embodiment of metadata associated with a directory or subdirectory is whether the signals contained within the directory or subdirectory should be treated as a collection. The ability to collect signals in this way can be useful when the set of signals is related and interdependent. An embodiment of collection data may be constituent signals that make up a location. For example, a location may be defined by (1) a longitude value, (2) a latitude value, and (3) an altitude value. Each of these values ​​is incomplete on its own and does not fully define a location. However, when collected together, the set of these three values ​​here defines a location. In this case, a directory or subdirectory having such a collection of signals may be designated as a collection in its metadata. Alternatively, the metadata associated with directories and subdirectories may be defined in a separate data structure distinct from the vehicle signal catalog, for example, in a separate file.

[0022] When an electronic unit is powered on, the various software components running on the electronic unit are initialized. This can involve the initialization of the operating system (OS), the communication service layer, and one or more applications. The communication service layer can be thought of as running on top of and / or utilizing the OS services. Applications can be thought of running on top of and / or utilizing the OS and the communication service layer. In some contexts, the communication service layer can be thought of as a middleware layer. The communication service layer can be thought of as operating in a manner similar to a software driver.

[0023] When the communication service layer is initialized, it reads the vehicle signal catalog, thereby learning the definitions of vehicle signals and metadata about vehicle signals and directories and subdirectories. In one embodiment, the communication service layer constructs a tree-like data structure in memory based on reading the vehicle signal catalog, which is conceptually equivalent to a file system, but the leaf nodes of the tree-like data structure correspond to vehicle signals rather than files. The communication service layer maps commands and / or requests associated with directories, subdirectories, and file names to an abstract structure maintained by the communication service layer, rather than to actual directories, subdirectories, and file names. In other words, the communication service layer constructs a tree-like data structure based on the vehicle signal catalog, where signals are leaf nodes and are represented as files in a file system, where discrete intermediate elements of a path are represented as directories.

[0024] A communications service layer on a given electronic unit may subscribe to receive updates regarding vehicle signals issued by other communications service layers running on other electronic units during or immediately after initialization. Similarly, a communications service layer may, during initialization, indicate vehicle signals that it will issue and / or make available to other authorized electronic units for reception. These actions of registering subscriptions and issuing in response to initialization establish an abstract communications link between communications service layers running on different electronic units.

[0025] After a communications service layer running on an electronic unit has been initialized and completed subscription and issuance notification or registration, an application running on the same electronic unit may request vehicle signal values ​​from the communications service layer, and the communications service layer may obtain the requested vehicle signal values ​​from another electronic unit (e.g., via the Automotive Area Network (CAN) bus in the vehicle) or directly from electromechanical systems and / or sensors coupled to the electronic unit. If the communications service layer receives information from electromechanical systems and / or sensors, it may convert the vehicle signal values ​​it receives into normalized values ​​and formats as defined by the vehicle signal catalog. The communications service layer then uses the normalized values ​​to issue vehicle signals.

[0026] In one embodiment, once the communication service layer is initialized, it may be invoked with one or more arguments that command the communication service layer to present vehicle signal values ​​in a preferred representation format. For example, when invoked in an actual production automated vehicle, the communication service layer may be commanded to present vehicle signal values ​​in a binary format that can be adapted to production software applications running on the electronic unit. When invoked in a test environment, for example in a virtualized environment, the communication service layer may be commanded to present vehicle signal values ​​in a different format more suitable for viewing by software testers and / or system integrators, for example, in ASCII format for presentation in a text editor. In one embodiment, when invoked, the communication service layer may be commanded to adopt English units (e.g., pounds, pounds per square inch, miles per hour, etc.) or, instead, SI units (e.g., kilograms, pascals, kilometers per hour, etc.).

[0027] In some embodiments, the communications service layer may modify its understanding of the vehicle signal catalog based on real-time commands. For example, in some embodiments, the communications service layer may respond to access control list (ACL) commands by adding, removing, and / or modifying the definitions of vehicle signals to its internal understanding of the vehicle signal catalog. This can support granting access to vehicle signals at runtime, rather than statically configuring access rights at compile time during development. In other words, using ACL commands with the communications service layer allows users and groups to be added (or have access revoked) with respect to access to vehicle signals and / or directories and / or subdirectories without restarting the communications service layer. Generally, ACLs can be used to add or revoke access permissions. This functionality can be particularly useful during testing and / or system integration.

[0028] The communication service layer, outlined above and described in further detail below, is a specific technical solution to the technical problem of providing access to vehicle signals while supporting flexibility and software reuse, and is embodied as software and / or firmware within an electronic unit or on a computer. The use of the communication service layer can reduce the redesign of software that would otherwise need to be embedded within an electronic unit and facilitate reuse by enabling a consistent and uniform process for accessing vehicle signals. In addition, many vehicle signal names may remain similar across vehicles using the models and approaches described herein. Thus, the RightRearDoorLockEngaged vehicle signal may be referenced in the same manner by software running in an electronic unit located in a passenger car and in an electronic unit located in a pickup truck, eliminating the need to recode this software before reuse.

[0029] Now looking at Figure 1, an automated vehicle 100 is described. The automated vehicle 100 may be a passenger car, a pickup truck, a sport utility vehicle (SUV), a minivan, a delivery van, a delivery truck, a camper van, a moving van, a moving truck, a towing vehicle for a semi-trailer, or other automated vehicle. In one embodiment, the automated vehicle 100 includes a first electronic unit 102 that communicates with a second electronic unit 122 via a network 124. In one embodiment, the network 124 may be an Automotive Area Network (CAN) bus. The automated vehicle 100 further includes one or more mechanical systems 126. At least some of the mechanical systems 126 may include sensors and / or electronic units 102, 122. For example, the engine may be a mechanical system 126 that includes electronic units 102, 122 that function as an engine electronic control unit.

[0030] Electronic units 102 and 122 can be considered embedded computers in the sense that they are computers that are essentially located within and interact with a larger electromechanical system. Other embodiments of the mechanical system may include wheel brakes, drivetrain transmissions, lights, brake lights and signal lights, heaters, air conditioning systems, and airbags. Embodiments of sensors may include tire pressure sensors, wheel speed sensors, temperature sensors, light sensors, precipitation sensors, radar sensors, and others. Embodiments of electronic units 102 and 122 include telematics units, engine control units, transmission control units, body control units, airbag control units, cabin air control units, main road condition recognition units, or navigation units.

[0031] The first electronic unit 102 comprises a processor (CPU) 104, a memory 106, and one or more input / output devices 108. The memory 106 may store a vehicle signal catalog 116 within a non-transient portion of the memory 106. The non-transient portion of the memory 106 may also store one or more applications 110, a communication service layer 112, and an operating system (OS) 114. When the electronic unit 102 is powered on, the OS 114 may be started and executed by the processor 104, the communication service layer 112 may be started and executed by the processor 104 after the OS 114 has been executed, and one or more applications 110 may be started and executed by the processor 104 after the OS 114 and the communication service layer 112 have been executed. The process of starting and executing the applications 110, the communication service layer 112, and the OS 114 may, in some contexts, be referred to as the startup and / or bootstrapping of the electronic unit 102. The OS 114, the communication service layer 112, and one or more applications 110 may be implemented as software, as firmware, or as a combination of software and firmware. It should be understood that the second electronic unit 122 (and optionally, additional electronic units) has a structure and components substantially similar to those illustrated and described with respect to the first electronic unit 102 in Figure 1. In one embodiment, the OS 114 is the QNX operating system.

[0032] The input / output device 108 may include a communication interface for linking the electronic unit 102 to the network 124 in a communicative manner. The input / output device 108 may also include an interface for linking the electronic unit 102 to one or more of the mechanical systems 126 and / or to electronic components within the mechanical systems 126, for example, to sensors and / or actuators associated with the mechanical systems 126. The input / output device 108 may also include a human / driver interface that can present indications on a display and / or receive user selections and / or control inputs.

[0033] In one embodiment, application 110 may register with or subscribe to the communication service layer 112 to receive updates regarding a particular vehicle signal. Vehicle signals may be defined by a vehicle signal catalog 116. Each vehicle signal may be identified as a full path file name and / or associated with a full path file name. A full path file name may comprise a root directory name, zero or more subdirectory names, and a file name. During initialization, the communication service layer 112 reads the vehicle signal catalog 116 and constructs a vehicle signal file system tree 118 in memory 106, which is conceptually equivalent to a file system, but its leaf nodes do not correspond to files, but instead correspond to vehicle signals. In one embodiment, the vehicle signal file system tree 118 may be stored in a transient portion of memory 106. In one embodiment, the vehicle signal catalog 116 is compatible with and / or consistent with a COVESA VSS document or model.

[0034] In some contexts of this specification, no distinction is maintained between the vehicle signal catalog 116 and the vehicle signal file system tree 118, and for simplification, actions that may be performed on the vehicle signal file system tree 118, such as searching for access rights in the vehicle signal file system tree 118, may instead be described herein as actions that may be performed on the vehicle signal catalog 116, such as searching for access rights in the vehicle signal catalog 116. The generation of the vehicle signal file system tree 118 based on the vehicle signal catalog 116 during initialization and the storage of this generated vehicle signal file system tree 118 within a transient portion of memory 106 are implementation details, and in other embodiments, it is assumed that different implementations may be used by the communication service layer 112.

[0035] The communication service layer 112 maps calls from application 110 to the vehicle signal file system tree 118 to appropriate actions on corresponding objects within the automated vehicle 100, such as reading tire pressure values ​​or writing values ​​to engine throttle positions (sending commands). In one embodiment, the communication service layer 112 uses a QNX resource manager to communicate with application 110 and / or other electronic units 102, 122. It should be understood that the QNX resource manager provides a highly efficient inter-process communication mechanism. However, in another embodiment, a different inter-process and / or inter-component communication framework may be used. The communication service layer 112 provides one or more application programming interfaces (APIs) that application 110 can call or invoke to use services provided by the communication service layer 112. In one embodiment, the APIs extended by the communication service layer 112 are POSIX APIs.

[0036] Application 110 may register that it will issue updates regarding specific vehicle signals. Application 110 may also perform many other functions, such as executing complex digital control algorithms to generate commands regarding the electromechanical components of vehicle 100 and transmit those commands to the electromechanical components (for example, generating a throttle command and transmitting it to the engine). Alternatively, Application 110 on electronic unit 102 may be primarily dedicated to supporting vehicle signal communication, and other applications running on electronic unit 102 may perform functions related to the control and / or monitoring of electromechanical components. The communication service layer 114 of electronic unit 102 may communicate with a corresponding communication service layer running on another electronic unit 122 via the network 124.

[0037] Now, looking to Figure 2, a virtual execution platform 140 is described. In one embodiment, some of the software and / or firmware described with reference to the automated vehicle 100 in Figure 1 may be executed, tested, and / or integrated on the virtual execution platform 140. It should be understood that testing and integrating application 110 on the electronic unit 102 and / or in the automated vehicle 100 may be impractical for various reasons. For example, the electronic unit 102 and / or the automated vehicle 100 may be too expensive for each software developer to use as a test platform for their own software or firmware development. A team of software developers for an automated vehicle may consist of 100 or more developers. It should be understood that the cost of providing each developer with an actual electronic unit 102 and / or the automated vehicle 100 for testing may be unaffordable. Furthermore, in some cases, the development of test software and / or firmware may take place in parallel with the development of the electronic unit 102 and / or the automated vehicle 100. In other words, by the time a software developer is able to test the software and / or firmware they have developed, the electronic unit 102 itself may not yet be complete in its development and / or production.

[0038] The virtual execution platform 140 comprises a processor 142 that runs one or more applications 110, a communication service layer 112, and an OS 114, a memory 144 that stores a vehicle signal catalog 116, and possibly a second processor that runs a stubing application 148. During initialization, the communication service layer 112 reads the vehicle signal catalog 116 and generates a vehicle signal file system tree 118 as described above with reference to Figure 1. The applications 110, the communication service layer 112, and the OS 114 may be substantially identical to the corresponding components described with reference to Figure 1. The processors 142, 144, and 146 may be virtual components provided as abstract structures by the virtual execution platform 140.

[0039] The stubing application 148 may provide functionality to simulate or substitute for other components of the automated vehicle 100 during the testing phase of software and / or firmware development. For example, if one of the functions of application 110 is to receive sensor values ​​from a sensor (e.g., from a wireless tire pressure sensor) and process this signal (e.g., issue a notification if the tire pressure falls below a predefined threshold), then the stubing application 148 may generate this value and transmit it to the communication service layer 112. The functionality in the stubing application 148 can be simple or complex. For example, the stubing application 148 may simply, arbitrarily, transmit a tire pressure value of 35 PSI in a first situation (e.g., above a predefined threshold) and a tire pressure value of 15 PSI in a second situation (e.g., below a predefined threshold). Alternatively, in one embodiment, the stubing application 148 may embody more complex processing, for example, it may generate and issue a sequence of tire pressure values ​​spanning the range of 35 PSI to 15 PSI while optionally executing a complex simulation scenario.

[0040] In a test and / or system integration environment, multiple workstations 152 may interact with the virtual execution platform 140. For example, a workstation 152 operated by a developer or tester may send commands to the communication service layer 112 and call POSIX APIs provided by the communication service layer 112. Workstation 152 may execute ACLs on the communication service layer 112 and modify permissions associated with directories, subdirectories, and / or filenames in the vehicle signal file system tree 118. Workstation 152 may execute POSIX-compatible command-line commands such as cd, ls, cat, mk dir, and echo. Workstation 152 may execute a command-line command with an argument to fetch metadata from the vehicle signal file system tree 118, for example, "LS / vehicle / . . . / LeftFrontTirePressure ?", where the "?" argument prompts the communication service layer 112 to return metadata associated with a given filename (e.g., a given vehicle signal). The workstation 152 may communicate with the virtual execution platform 140 via the network 150. The network 150 comprises one or more private networks, one or more public networks, or a combination thereof.

[0041] Now, looking at Figure 3, Method 200 is described. In one embodiment, Method 200 is a method for acquiring vehicle signal data by an application running on a processor. For example, a communication service layer 112 and application 110 running on electronic units 102, 122 or on a virtual execution platform 140 may implement Method 200. In block 202, Method 200 includes reading a vehicle signal catalog by a communication service layer application running on a computer system, where the vehicle signal catalog defines vehicle signals as full-path filenames, each full-path filename comprising one or more containing directory names and a filename that identifies the vehicle signal. In one embodiment, the computer system is a virtual execution platform, e.g., a virtual execution platform in a test and / or integration environment. The virtual execution platform may rely on computing and memory resources provided by a cloud computing system. In one embodiment, the computer system is an electronics unit located within an automated vehicle. In block 204, method 200 includes receiving a request for a vehicle signal value from a second application running on a computer system via a communication service layer application, the request being received via a POSIX interface provided by the communication service layer application, and the request identifying the vehicle signal as a full path file name.

[0042] Optionally, in block 206, method 200 includes a communication service layer application determining an access definition for a vehicle signal based on a vehicle signal catalog. In one embodiment, the full path file names in the vehicle signal catalog are compatible with a POSIX directory structure, and the access definitions for vehicle signals are defined in the vehicle signal catalog using POSIX file name access permissions. Optionally, in block 208, method 200 includes a communication service layer application determining, based on the access definition for the vehicle signal and based on the identification of the second application, that a second application has read access permissions for the vehicle signal identified in the request. While performing the operations in blocks 206 and 208 may be desirable to enhance security, it should be understood that in one embodiment, the operations in blocks 206 and 208 may be omitted. For example, under certain circumstances, an application or multiple applications capable of sending requests to the communication service layer regarding vehicle signal values ​​may be inherently trusted, in which case no security advantage is actually gained by performing the processing of blocks 206 and 208, and increased efficiency can be achieved by omitting the processing of blocks 206 and 208.

[0043] In block 210, method 200 includes obtaining a value of a vehicle signal identified in a request by a communication service layer application. In one embodiment, the communication service layer application may obtain a value of the vehicle signal from another electronic unit located within the automated vehicle. In one embodiment, the communication service layer application may obtain a value of the vehicle signal from an Automotive Area Network (CAN) bus located within the automated vehicle. In one embodiment, the communication service layer application may obtain a value of the vehicle signal from a stubing application running on a computer system, for example, when the communication service layer application is running in a test and / or system integration environment. In block 212, method 200 includes returning a value of a vehicle signal identified in a request to a second application.

[0044] In one embodiment, the vehicle signal catalog includes metadata associated with directory names and file names. In another embodiment, the metadata associated with the directory names and file names of the vehicle signals is defined, for example, in a file separate from the vehicle signal catalog in the memory of the computer system.

[0045] Now, looking at Figures 4A and 4B, Method 220 is described. In one embodiment, Method 220 is a method for obtaining vehicle signal data by an application running on a processor. In block 222, Method 220 includes reading a vehicle signal catalog by a communications service layer application running on a computer system, where the vehicle signal catalog defines vehicle signals as full-path filenames, each full-path filename comprising one or more containing directory names and a filename that identifies the vehicle signal. In one embodiment, the communications service layer application runs on a QNX operating system installed on a computer system (e.g., it runs, accesses memory, and relies on services provided by the QNX operating system to access input / output resources). In one embodiment, the full-path filenames in the vehicle signal catalog are compatible with a POSIX directory structure, and the access definitions for vehicle signals are defined in the vehicle signal catalog using POSIX filename access permissions.

[0046] In block 224, method 220 includes receiving a first request from a second application running on a computer system, via a communication service layer application, for a value of a vehicle signal, the first request identifying the vehicle signal as a full path file name. In block 226, method 220 includes, in response to receiving the first request, determining a first access definition for the vehicle signal via the communication service layer application based on a vehicle signal catalog.

[0047] In block 228, method 220 includes the communication service layer application determining, based on a first access definition for the vehicle signal and based on the identification of the second application, that the second application has read access permission for the vehicle signal identified in the first request. In block 230, method 220 includes the communication service layer application obtaining the value of the vehicle signal identified in the first request. In one embodiment, the communication service layer application uses the QNX Resource Manager Application Programming Interface (API) to obtain the value of the vehicle signal identified in the first request.

[0048] In block 232, method 220 includes returning the value of the vehicle signal identified in the first request to a second application. In one embodiment, method 220 further includes providing a data format type to the communication service layer application when the communication service layer application is initialized, and the data format of the value of the vehicle signal identified in the first request, which is returned to the second application, is defined by the data format type provided during the initialization of the communication service layer application. In one embodiment, the data format type is either a binary data type or an ASCII data type.

[0049] In block 234, method 220 includes the communication service layer application executing an access control list (ACL) command, in which the ACL command replaces a first access definition for a vehicle signal with a second access definition in the vehicle signal catalog. In block 236, method 220 includes the communication service layer application receiving a second request from a second application for a value of a vehicle signal, the second request identifying the vehicle signal as a full path file name. In block 238, method 220 includes the communication service layer application determining a second access definition for a vehicle signal based on the vehicle signal catalog in response to receiving the second request.

[0050] In block 240, method 220 includes the communication service layer application determining, based on a second access definition for the vehicle signal and on the identification of the second application, that the second application does not have read access permission for the vehicle signal identified in the second request. In block 242, method 220 includes returning a rejection of the second request to the second application.

[0051] Figure 5 illustrates a computer system 380 suitable for implementing one or more embodiments disclosed herein. The computer system 380 includes a processor 382 (which may be referred to as a central processor unit or CPU), which communicates with memory devices including a secondary storage device 384, read-only memory (ROM) 386, and random access memory (RAM) 388, an input / output (I / O) device 390, and a network connectivity device 392. The processor 382 may be implemented as one or more CPU chips.

[0052] It should be understood that by programming and / or loading executable instructions onto the computer system 380, at least one of the CPU 382, ​​RAM 388, and ROM 386 is modified, thereby transforming the computer system 380 into a particular machine or device having novel functionality taught herein. It is fundamental to the fields of electrical and software engineering that functionality that can be implemented by loading executable software onto a computer can be translated into hardware implementations by well-known design rules. The decision of whether to implement a concept in software or hardware typically depends on considerations of design stability and the number of units to be produced, rather than any issues involved in translating from the software domain to the hardware domain. Generally, designs that are still subject to frequent changes may be preferred to be implemented in software, since redesigning the hardware implementation is more expensive than redesigning the software. Generally, stable designs that will be mass-produced may be preferred to be implemented in hardware, for example in application-specific integrated circuits (ASICs), because, with respect to the mass production process, hardware implementation may not be more expensive than software implementation. In many cases, designs are developed and tested in software form and can later be transformed, according to well-known design rules, into equivalent hardware implementations in application-specific integrated circuits that physically incorporate the software instructions. In the same manner that a machine controlled by a new ASIC is a specific machine or device, a computer programmed and / or loaded with executable instructions can similarly be considered a specific machine or device.

[0053] In addition, after system 380 is turned on or started, CPU 382 may execute computer programs or applications. For example, CPU 382 may execute software or firmware stored in ROM 386 or RAM 388. In some cases, at startup and / or when an application is started, CPU 382 may copy the application or part of an application from secondary storage device 384 to RAM 388 or to memory space within CPU 382 itself, and CPU 382 may then execute instructions contained in the application. In some cases, CPU 382 may copy the application or part of an application from memory accessed via network connectivity device 392 or I / O device 390 to RAM 388 or to memory space within CPU 382, ​​and CPU 382 may then execute instructions contained in the application. During execution, the application loads instructions into CPU 382, ​​for example, some of the application's instructions may be loaded into CPU 382's cache. In some contexts, an application being executed may be considered to configure the CPU 382 to do something, for example, to perform one or more functions facilitated by this application. When the CPU 382 is configured in this way by an application, the CPU 382 becomes a purpose-specific computer or purpose-specific machine.

[0054] The secondary storage device 384 typically includes one or more disk drives or tape drives and is used for non-volatile storage of data, and as an overflow data storage device if the RAM 388 is not large enough to hold all the working data. The secondary storage device 384 may also be used to store programs that are loaded into the RAM 388 when such programs are selected for execution. The ROM 386 is used to store instructions and, optionally, data that are read during program execution. The ROM 386 is typically a non-volatile memory device with a smaller memory capacity compared to the larger memory capacity of the secondary storage device 384. The RAM 388 is used to store volatile data and, optionally, instructions. Access to both the ROM 386 and the RAM 388 is typically faster than access to the secondary storage device 384. The secondary storage device 384, the RAM 388, and / or the ROM 386 may, in some contexts, be referred to as computer-readable storage media and / or non-transient computer-readable media.

[0055] The I / O device 390 may include a printer, video monitor, liquid crystal display (LCD), touchscreen display, keyboard, keypad, switch, dial, mouse, trackball, voice recognition device, card reader, paper tape reader, or other well-known input devices.

[0056] The network connectivity device 392 may take the form of a modem, modem bank, Ethernet® card, Universal Serial Bus (USB) interface card, serial interface, Token Ring card, Fiber Optic Distributed Data Interface (FDDI) card, Wireless Local Area Network (WLAN) card, Wireless transceiver card, and / or other well-known network devices. The network connectivity device 392 may provide wired communication links and / or wireless communication links (for example, the first network connectivity device 392 may provide a wired communication link, and the second network connectivity device 392 may provide a wireless communication link). The wired communication links may be provided in accordance with Ethernet® (IEEE 802.3), Internet Protocol (IP), Time Division Multiplexing (TDM), Data Services Interface Standard over Cable (DOCSIS), Wavelength Division Multiplexing (WDM), and / or equivalents. In one embodiment, the wireless transceiver card may provide a wireless communication link using protocols such as Code Division Multiple Access (CDMA), Global Mobile Telephony System (GSM®), Long-Term Evolution (LTE), Wi-Fi (IEEE 802.11), Bluetooth®, Zigbee®, Narrowband Internet of Things (NB IoT), Near Field Communication (NFC), and Radio Frequency Identification (RFID). The wireless transceiver card may facilitate wireless communication using 5G, 5G Nova Radio, or 5G LTE wireless communication protocols. These network connectivity devices 392 may enable the processor 382 to communicate with the Internet or one or more intranets. It is assumed that by using such network connectivity, the processor 382 may be able to receive information from or output information to the network in the process of carrying out the method steps described above.In many cases, such information, which is represented as a sequence of instructions to be executed using processor 382, ​​may be received from and output to the network, for example, in the form of computer data signals embodied on a carrier wave.

[0057] For example, such information, which may include data or instructions to be executed using processor 382, ​​may be received from and output to the network, for example, in the form of a signal embodied in a computer database band signal or carrier wave. Signals embedded in baseband signals or carrier waves, or other types of signals currently in use or to be developed in the future, may be generated according to several methods well known to those skilled in the art. Baseband signals and / or signals embedded in carrier waves may, in some contexts, be referred to as transient signals.

[0058] Processor 382 executes instructions, code, computer programs, and scripts that it accesses from a hard disk, floppy disk, optical disk (all of these various disk-based systems can be considered secondary storage devices 384), flash drive, ROM 386, RAM 388, or network connectivity device 392. While only one processor 382 is shown, multiple processors may be present. Therefore, instructions can be discussed as being executed by a processor, but instructions may be executed simultaneously, sequentially, or otherwise by one or more processors. Instructions, code, computer programs, scripts, and / or data that can be accessed from secondary storage devices 384, e.g., hard drives, floppy disks, optical disks, and / or other devices, ROM 386, and / or RAM 388, may in some contexts be referred to as non-transient instructions and / or non-transient information.

[0059] In one embodiment, computer system 380 may comprise two or more computers that communicate with each other and cooperate to perform tasks. For example, but not limited to, applications may be partitioned in such a way that concurrent and / or parallel processing of application instructions is possible. Alternatively, data processed by applications may be partitioned in such a way that concurrent and / or parallel processing of different parts of a dataset by two or more computers is possible. In one embodiment, virtualization software may be employed by computer system 380 to provide the functionality of a number of servers that is not directly constrained by the number of computers in computer system 380. For example, virtualization software may provide 20 virtual servers on four physical computers. In one embodiment, the functionality disclosed above may be provided by running applications and / or multiple applications within a cloud computing environment. Cloud computing may include providing computing services over network connectivity using dynamically scalable computing resources. Cloud computing may be supported, at least in part, by virtualization software. The cloud computing environment may be established by an enterprise and / or leased as needed from a third-party provider. Some cloud computing environments may include cloud computing resources owned and operated by the enterprise, as well as cloud computing resources leased and / or rented from third-party providers.

[0060] In some embodiments, some or all of the functionalities disclosed above may be provided as a computer program product. The computer program product may comprise one or more computer-readable storage media, each having computer-usable program code embodied therein to implement the functionalities disclosed above. The computer program product may comprise data structures, executable instructions, and other computer-usable program code. The computer program product may be embodied in removable computer storage media and / or non-removable computer storage media. Removable computer-readable storage media may include, but are not limited to, paper tape, magnetic tape, magnetic disks, optical disks, solid-state memory chips, such as analog magnetic tape, compact disc read-only memory (CD-ROM) disks, floppy disks, jump drives, digital cards, multimedia cards, and others. The computer program product may be suitable for the computer system 380 to load at least a portion of the contents of the computer program product into a secondary storage device 384, ROM 386, RAM 388, and / or other non-volatile and volatile memories of the computer system 380. The processor 382 may process executable instructions and / or data structures in part by directly accessing the computer program product, for example, by reading from a CD-ROM disk inserted into a disk drive peripheral of the computer system 380. Alternatively, the processor 382 may process executable instructions and / or data structures by remotely accessing the computer program product, for example, by downloading executable instructions and / or data structures from a remote server through a network connectivity device 392.The computer program product may include instructions that facilitate the loading and / or copying of data, data structures, files, and / or executable instructions to the secondary storage device 384, to the ROM 386, to the RAM 388, and / or other non-volatile and volatile memories of the computer system 380.

[0061] In some contexts, the secondary storage device 384, ROM 386, and RAM 388 may be referred to as non-transient computer-readable media or computer-readable storage media. A dynamic RAM embodiment of RAM 388 may similarly be referred to as non-transient computer-readable media in that the dynamic RAM stores information to be written to it while it is powered and operated according to its design, for example, during the period when the computer system 380 is turned on and operating. Similarly, the processor 382 may include internal RAM, internal ROM, cache memory, and / or other internal non-transient storage blocks, sections, or components which may be referred to as non-transient computer-readable media or computer-readable storage media in some contexts.

[0062] While several embodiments are provided in this disclosure, it should be understood that the disclosed systems and methods can be embodied in many other specific forms without departing from the spirit or scope of this disclosure. These embodiments are intended to be illustrative, not restrictive, and their intent is not limited to the details given herein. For example, various elements or components may be combined or integrated within another system, or certain features may be omitted or not implemented at all.

[0063] Furthermore, techniques, systems, subsystems, and methods described and illustrated in various embodiments as discrete or distinct may be combined with or integrated with other systems, modules, techniques, or methods without departing from the scope of this disclosure. Other items shown or discussed as directly coupled or communicating with one another may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other embodiments of modification, substitution, and alteration may be observable to those skilled in the art and may be made without departing from the spirit and scope disclosed herein.

Claims

1. An in-vehicle electronic unit equipped with a communication service layer, Processor and A memory wherein the non-transient portion of the memory stores a vehicle signal catalog that defines vehicle signals as full path filenames, and each full path filename comprises one or more containing directory names and a filename that identifies a vehicle signal. An operating system (OS) stored in the non-transient portion of the memory, wherein the OS, when executed by the processor, manages access to the memory and manages access to the processor. An application stored in the non-transient portion of the memory, wherein the application, when executed by the processor, processes at least one vehicle signal. A communication service layer stored in the non-transient portion of the memory, wherein the communication service layer is executed by the processor, In response to the initialization of the communication service layer, the vehicle signal catalog is read from the non-transient portion of the memory, The application receives a request to access a vehicle signal, the request identifies the vehicle signal using the full path file name associated with the vehicle signal, To obtain the first value of the aforementioned vehicle signal, Based on the definition of the normalized value for the vehicle signal in the aforementioned catalog, the first value of the vehicle signal is mapped to the second value, The second value described above is returned to the application. The communication service layer performs the following An in-vehicle electronic unit equipped with the following features.

2. The communication service layer, before acquiring the first value of the vehicle signal, Searching for access rights definitions related to the full path file name identified in the request within the vehicle signal catalog, The identification of the aforementioned application is compared with the access rights definition, Based on comparing the identification of the application with the access rights definition, it is determined that the application has permission to access the vehicle signal. The in-vehicle electronic unit according to claim 1, which performs the following:

3. The in-vehicle electronic unit according to claim 2, wherein the vehicle signal catalog defines access rights to directories in addition to file names that define vehicle signals.

4. The in-vehicle electronic unit according to claim 1, wherein the OS is the QNX operating system.

5. The in-vehicle electronic unit according to claim 4, wherein the communication service layer executes an access control list (ACL) command and adds a vehicle signal to the vehicle signal catalog.

6. The in-vehicle electronic unit according to claim 1, wherein the communication service layer provides a POSIX interface, receives the request from the application via the POSIX interface, and returns the second value to the application via the POSIX interface.

7. The in-vehicle electronic unit according to claim 1, wherein the in-vehicle electronic unit is one of a telematics unit, an engine control unit, a body control unit, an airbag control unit, a cabin air control unit, a main road condition recognition unit, or a navigation unit.

8. The in-vehicle electronic unit according to claim 1, wherein the in-vehicle electronic unit is located in a towing vehicle for a passenger car, pickup truck, sport utility vehicle (SUV), minivan, delivery van, delivery truck, camper van, moving van, moving truck, or semi-trailer.

9. A method for acquiring vehicle signal data by an application running on a processor, A communication service layer application running on a computer system reads a vehicle signal catalog, wherein the vehicle signal catalog defines vehicle signals as full-path filenames, and each full-path filename comprises one or more containing directory names and a filename that identifies the vehicle signal. The communication service layer application receives a request regarding the value of a vehicle signal from a second application running on the computer system, the request is received via a POSIX interface provided by the communication service layer application, and the request identifies the vehicle signal as a full path file name. The communication service layer application obtains the value of the vehicle signal identified in the request, The value of the vehicle signal identified in the request is returned to the second application. Methods that include...

10. The method according to claim 9, wherein the computer system is an electronic device unit located inside an automated vehicle.

11. The method according to claim 9, wherein the computer system is a virtual execution platform.

12. Based on the aforementioned vehicle signal catalog, the communication service layer application determines the access definition for the vehicle signal, Based on the access definition relating to the vehicle signal and the identification of the second application, the communication service layer application determines that the second application has read access permission relating to the vehicle signal identified in the request. It further includes, The method according to claim 9, wherein the full path file name in the vehicle signal catalog is compatible with the POSIX directory structure, and the access definition of the vehicle signal is defined in the vehicle signal catalog using POSIX file name access permissions.

13. The method according to claim 9, wherein the vehicle signal catalog comprises metadata associated with the directory name and the file name.

14. The method according to claim 9, wherein the metadata associated with the directory name and file name of the vehicle signal is defined in a separate file in the memory of the computer system.

15. A method for acquiring vehicle signal data by an application running on a processor, A communication service layer application running on a computer system reads a vehicle signal catalog, wherein the vehicle signal catalog defines vehicle signals as full-path filenames, and each full-path filename comprises one or more containing directory names and a filename that identifies the vehicle signal. The communication service layer application receives a first request regarding the value of a vehicle signal from a second application running on the computer system, wherein the first request identifies the vehicle signal as a full path file name. In response to receiving the first request, the communication service layer application determines a first access definition relating to the vehicle signal based on the vehicle signal catalog, The communication service layer application determines, based on the first access definition relating to the vehicle signal and based on the identification of the second application, that the second application has read access permission relating to the vehicle signal identified in the first request. The communication service layer application obtains the value of the vehicle signal identified in the first request, The value of the vehicle signal identified in the first request is returned to the second application, The communication service layer application executes an access control list (ACL) command, wherein the ACL command replaces the first access definition relating to the vehicle signal with a second access definition in the vehicle signal catalog. The second application receives a second request regarding the value of the vehicle signal via the communication service layer application, wherein the second request identifies the vehicle signal as a full path file name. In response to receiving the second request, the communication service layer application determines the second access definition relating to the vehicle signal based on the vehicle signal catalog, The communication service layer application determines, based on the second access definition relating to the vehicle signal and the identification of the second application, that the second application does not have read access permission relating to the vehicle signal identified in the second request. Returning the rejection of the second request to the second application Methods that include...

16. The method according to claim 15, wherein the communication service layer application runs on the QNX operating system installed on the computer system.

17. The method according to claim 16, wherein the communication service layer application uses the QNX Resource Manager Application Programming Interface (API) to obtain the value of the vehicle signal identified in the first request.

18. The method according to claim 15, wherein the full path file name in the vehicle signal catalog is compatible with the POSIX directory structure, and the access definition of the vehicle signal is defined in the vehicle signal catalog using POSIX file name access permissions.

19. The method of claim 15, further comprising providing a data format type to the communication service layer application when the communication service layer application is initialized, wherein the data format of the value of the vehicle signal identified in the first request returned to the second application is defined by the data format type provided during the initialization of the communication service layer application.

20. The method according to claim 19, wherein the data format type is one of a binary data type, a floating-point data type, an ASCII data type, and an EBCIDIIC data type.

Images