Systems and methods for layered application program interfaces for vehicle applications

Abstract

To provide an apparatus and method for providing an interface for a vehicle application.SOLUTION: At least one processor configured to execute instructions to provide a layered application programming interface (API) having a memory storing instructions, a direct interface layer having at least one signal source, a unit conversion layer configured to receive signal data from the at least one signal source and convert the signal data to a standardized format, and a processing layer configured to process the converted signal data from the unit conversion layer into processed signal data that can be interpreted by at least one application; The method includes: SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] Systems and methods consistent with example embodiments of the present disclosure relate to a layered application program interface (API) for vehicle applications. [Background technology]

[0002] In the related art, vehicle-related applications may be developed to perform various functions. For example, in the case of an autonomous vehicle, various sensor data may need to be collected for feedback and processed to perform corrective actions on steering. Various interfaces and variables may be created, for example, each sensor may define its own interface, and raw data may be collected, converted, and processed before being used by the application.

[0003] Related technologies may introduce too many interfaces and variables to be efficiently managed. Vehicle software, in particular, can be highly complex and difficult to abstract due to the large number of variables and dependencies, both hardware and software. For example, each sensor may use different firmware, and therefore the way interactions are handled for one sensor may be completely different for a second sensor. Also, the units output from the sensors may be different. Summary of the Invention

[0004] As a result of the complex nature of vehicle software, troubleshooting errors that occur during code embedding can be very difficult because it is difficult to trace the source of the error.

[0005] Therefore, there is a need for a more streamlined structure for vehicle software that can separate interfaces and variables into a more manageable and controllable format.

[0006] According to one or more exemplary embodiments, an apparatus and method for providing an interface for vehicle applications is provided. Specifically, the apparatus may include a memory that stores instructions, at least one processor configured to execute instructions to provide a layered application programming interface (API), the API having a direct interface layer having at least one signal source, a unit conversion layer configured to receive signal data from the at least one signal source and convert the signal data to a standardized format, and a processing layer configured to process the converted signal data from the unit conversion layer into processed signal data that can be interpreted by at least one application.

[0007] According to an embodiment, the layered API may further include a normalization layer that normalizes the converted signal data from the unit conversion layer into normalized signal data that is sent to at least one application. The normalized signal data may include a percentage. The converted signal data may include an image in a first dimension, and the normalized signal data may include an image in a second dimension that is different from the first dimension.

[0008] According to an embodiment, the layered API may further include a signal validity layer configured to combine multiple received signal data from multiple signal sources and send a validity flag to at least one application based on determining validity of the combined multiple received signal data. The validity flag may indicate whether the received signal data is valid. The validity flag may further indicate whether the received signal data is degraded or blocked.

[0009] According to an embodiment, there may be provided a method for providing an interface for a vehicle application, the method being executable by a processor to receive, by a unit conversion layer of a layered application programming interface (API), signal data from at least one signal source of a direct interface layer of the layered API, converting, by the unit conversion layer, the received signal data into converted signal data in a standardized format, and processing, by a processing layer of the layered API, the converted signal data into processed signal data that can be interpreted by the at least one application.

[0010] According to an embodiment, the method may further include normalizing the converted signal data into normalized signal data by a normalization layer of the layered API and transmitting the normalized signal data by the normalization layer to at least one application. The normalized signal data may include a ratio. The converted signal data may include an image at a first magnitude, and the normalized signal data may include an image at a second magnitude different from the first magnitude.

[0011] According to an embodiment, the method may further include combining, by a signal validity layer of the layered API, the plurality of received signal data from the plurality of signal sources, and transmitting a validity flag to at least one application based on determining, by the signal validity layer, validity of the combined plurality of received signal data. The validity flag may indicate whether the received signal data is valid. The validity flag may further indicate whether the received signal data is degraded or blocked.

[0012] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be realized by practice of the presented embodiments of the present disclosure.

[0013] Features, aspects, and advantages of certain exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which like reference numerals refer to like elements. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 is a diagram of exemplary components of an apparatus according to an exemplary embodiment. [Figure 2] FIG. 2 is a block diagram illustrating a typical layered application programming interface (API) stack, according to one or more exemplary embodiments. [Figure 3] FIG. 3 is a block diagram illustrating an example implementation of a layered API stack in accordance with one or more example embodiments. [Figure 4] FIG. 4 is a flowchart diagram illustrating a method for translating sensor data received from a direct interface layer for an application, according to one or more exemplary embodiments. [Figure 5] FIG. 5 is a flowchart diagram illustrating a method for translating application instructions to a direct interface layer according to one or more exemplary embodiments. [Figure 6] FIG. 6 is a flowchart diagram illustrating a method 600 for using a signal availability layer, according to one or more exemplary embodiments. [Figure 7] FIG. 7 is a flowchart illustrating a method for automatic Interface Description Language (IDL) file generation in accordance with one or more exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0015] The following detailed description of exemplary embodiments refers to the accompanying drawings. While the present disclosure provides illustration and description, it is not intended to be exhaustive or to limit one or more exemplary embodiments to the precise form disclosed. Modifications and variations are possible in light of the present disclosure or may be acquired from the practice of one or more exemplary embodiments. Moreover, one or more features or components of one exemplary embodiment may be incorporated into or combined with another exemplary embodiment (or one or more features of another exemplary embodiment). Furthermore, in the flowcharts and operational descriptions provided herein, it should be understood that one or more operations may be omitted, one or more operations may be added, one or more operations may be performed concurrently (at least in part), and the order of one or more operations may be switched.

[0016] It will be apparent that exemplary embodiments of the systems and / or methods and / or non-transitory computer-readable storage media described herein may be implemented in different forms, such as hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods does not limit one or more embodiments. Thus, the operation of the systems and / or methods and / or non-transitory computer-readable storage media is described herein without reference to specific software code. It should be understood that software and hardware may be designed to implement the systems and / or methods based on the description herein.

[0017] Although particular combinations of features are recited in the claims and / or disclosed herein, these combinations are not intended to limit the disclosure of possible example embodiments. Indeed, many of these features can be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible example embodiments includes each dependent claim in combination with all other claims in the claim set.

[0018] No element, act, or instruction used herein should be construed as critical or required unless explicitly stated as such. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "one" or similar language is used. Also, as used herein, terms such as "has," "hab," "having," "include," and "including" are intended to be open terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on" unless otherwise specified. Furthermore, phrases such as "at least one of [A] and [B]" or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0019] A layered API according to exemplary embodiments may include a process for generating code using an interface definition language (IDL). In particular, an apparatus and method according to exemplary embodiments may include a direct interface layer having at least one signal source; a unit conversion layer configured to receive signal data from the at least one signal source and convert the signal data into a standardized format; and a processing layer configured to process the converted signal data from the unit conversion layer into processed signal data that can be interpreted by at least one application. Depending on the particular application, additional layers may be included, such as a signal validity layer (to verify data validity) and a normalization layer (to convert data into a more consistent format), although it should be noted that the particular arrangement of layers may depend on the particular application. Furthermore, an apparatus and method according to exemplary embodiments may include a method for converting an API defined by the layered API in the form of a specification file into code (e.g., in an IDL format).

[0020] 1 is a diagram of example components of device 100. As shown in FIG. 1, device 100 may include a bus 110, a processor 120, a memory 130, a storage component 140, an input component 150, an output component 160, and a communication interface 170.

[0021] Bus 110 includes components that enable communication between components of device 100. Processor 120 can be implemented in hardware, firmware, or a combination of hardware and software. Processor 120 may be a central processing unit (CPU), graphics processing unit (GPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or another type of processing component. In one or more embodiments, processor 120 includes one or more processors that are programmable to perform functions. Memory 130 includes random access memory (RAM), read-only memory (ROM), and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, and / or optical memory) that stores information and / or instructions used by processor 120.

[0022] The storage component 140 stores information and / or software related to the operation and use of the device 100. For example, the storage component 140 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or another type of non-transitory computer-readable medium, along with a corresponding drive. The input component 150 includes components that enable the device 100 to receive information, such as via user input (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone). Additionally or alternatively, the input component 150 may include sensors for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or an actuator). The output component 160 includes components that provide output information from the device 100 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0023] Communications interface 170 includes transceiver-like components (e.g., a transceiver and / or a separate receiver and transmitter) that enable device 100 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. Communications interface 170 may enable device 100 to receive information from and / or provide information to other devices. For example, communications interface 170 may include, but is not limited to, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, etc.

[0024] Device 100 may perform one or more example processes described herein. According to one or more embodiments, device 100 may perform these processes in response to processor 120 executing software instructions stored by a non-transitory computer-readable medium, such as memory 130 and / or storage component 140. Computer-readable medium is defined herein as a non-transitory storage device. Storage includes memory space within a single physical storage device or memory space distributed across multiple physical storage devices.

[0025] The software instructions may be read into memory 130 and / or storage component 140 from another computer-readable medium or from another device via communications interface 170. When executed, the software instructions stored in memory 130 and / or storage component 140 may cause processor 120 to perform one or more operations described herein.

[0026] Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more of the operations described herein. Thus, one or more exemplary embodiments described herein are not limited to any specific combination of hardware circuitry and software.

[0027] The number and arrangement of components shown in Figure 1 are provided as an example. In practice, apparatus 100 may include additional, fewer, different, or differently arranged components than those shown in Figure 1. Additionally or alternatively, a set of components (e.g., one or more components) of apparatus 100 may perform one or more functions that are described as being performed by another set of components of apparatus 100.

[0028] 2 is a block diagram illustrating a typical layered application programming interface (API) stack in accordance with one or more exemplary embodiments. The layered API may include an application 200 and multiple abstraction layers (e.g., a signal validity layer 210, a normalization layer 220, a processing / fusion layer 230, a unit conversion layer 240, and a direct interface layer 250).

[0029] According to an embodiment, to create a more convenient interface for application 200 (such as an application that may be used in a vehicle), an abstraction layer for the API may be provided that may control access to direct interface layer 250 (such as a sensor that may act as a signal source). Direct interface layer 250 may have one or more direct interface layer elements 250-1, 250-2, ..., 250-N, each of which may correspond to different vehicle hardware / sensors. While each abstraction layer should include at least one input from either direct interface layer 250 or another abstraction layer, it should be understood that there is no upper limit (e.g., other than physical constraints) on the number of inputs a given abstraction layer can receive. Each abstraction layer may include an output that may provide an output signal to another abstraction layer, application 200, or direct interface layer 250. To bridge between direct interface layer 250 and application 200, multiple abstraction layers may form a layered API.

[0030] The lowest abstraction layer in the layered API stack (i.e., closest to the direct interface layer 250) may receive the largest amount of raw data, and during processing moving up the layer stack (i.e., toward the application 200), the data may be more refined and the amount of data may be reduced.

[0031] According to an embodiment, an exemplary abstraction layer that may be at the lowest level is unit conversion layer 240. Unit conversion layer 240 may be configured to convert data in a format specific to an interface (such as a sensor) in direct interface layer 250 to a standardized format (e.g., an agreed-upon standard for an OEM or supplier), or vice versa. Unit conversion layer 240 may be composed of one or more elements (unit conversion layer elements 241-1, 241-2, ... 241-N), which may be configured with different logic for handling conversions for different elements in direct interface layer 250, according to an embodiment.

[0032] As an example of using unit conversion layer 240, a vehicle speedometer may record sensor data for speed in km / h (e.g., the vehicle speedometer may be direct interface layer element 251-1), but application 200 or another abstraction layer may require the speed data to be in a standardized m / s format. Thus, unit conversion layer 240 may include an element (e.g., unit conversion layer element 241-1) that contains logic to convert km / h received from direct interface layer 250 to m / s for use by a higher abstraction layer.

[0033] As another example of using unit conversion layer 240, application 200 or a higher abstraction layer may intend to actuate a brake to provide braking force in standardized units of Newtons, but the brake actuator (as implemented in direct interface layer 250) may only receive instructions in kgm / s^2. Thus, unit conversion layer 240 may include elements for converting actuator force values ​​received in Newtons from a higher abstraction layer to kgm / s^2 for direct interface layer 250. The logic used in elements for unit conversion layer 240 may depend on the particular implementation.

[0034] According to an embodiment, processing / fusion layer 230 may be provided as another exemplary abstraction layer. Processing / fusion layer 230 may receive one or more standardized data signals from lower layers (which may be vehicle sensor-specific data, such as from unit conversion layer 240, or direct interface layer 250 if direct interface layer 250 already transmits data in a standardized format) and perform processing to output data useful for use by the interface of application 200. Processing / fusion layer 230 may comprise one or more elements (processing / fusion layer elements 231-1, 231-2, ..., 231-N) that may be configured with different logic for handling processes.

[0035] As an example of utilizing the processing / fusion layer 230, if application 200 requests vehicle speed, there may be multiple signals to check to verify vehicle speed (e.g., GPS speed, wheel speed, etc.). Thus, in one embodiment, an element in the processing / fusion layer 230 (e.g., processing / fusion layer element 231-1) may compare one signal to another to check which sensor is more accurate and provide the most accurate signal. According to another embodiment, an element in the processing / fusion layer 230 may provide a weighted average of the signals based on which sensor is more reliable. In some cases, the output from the element in the processing / fusion layer 230 to the application may also include a confidence assessment regarding the quality of the data provided based on performing the comparison.

[0036] As another example of using the processing / fusion layer 230, an emergency braking function can be implemented. Element 231-1 in the processing / fusion layer 230 can receive input from multiple signal sources (e.g., radar, LiDAR, camera, either from unit conversion layer 240 or from direct interface layer 250) and can send a signal to application 200 only if at least two of the signal sources indicate the presence of an oncoming object detected. When application 200 receives a signal that an oncoming object appears to be detected, it can send a command down the layered API stack (toward direct interface layer 250) to activate braking force using direct interface layer 250 to cause the brakes to perform a braking maneuver.

[0037] According to some embodiments, processing / merging layer 230 may be used for conversion of additional data types other than the standardized format received from direct interface layer 250 or unit conversion layer 240. For example, if the received camera input signal is in RGB format and application 200 requires BRG format, elements in processing / merging layer 230 may perform conversion between RGB format and BRG format. Similarly, as another example, processing / merging layer 230 may provide elements that perform conversion between Cartesian coordinates and polar coordinates (or vice versa).

[0038] 2 and described herein, it should be understood that multiple processing / merging layers 230 may be used depending on the particular implementation (provided the physical limitations of the system implementing the layered API stack are met). For example, a first processing / merging layer 230 may be dedicated to processing camera data, and a second processing / merging layer 230 may be dedicated to further unit conversion.

[0039] According to an embodiment, normalization layer 220 may be provided as an abstraction layer that converts more vehicle-dependent data received from a lower layer (such as unit conversion layer 240 or direct interface layer 250) into a normalized data signal (a more consistent format) usable by application 200, or vice versa. In particular, normalization layer 220 may be useful in scenarios where it is more convenient for application 200 to represent data from the vehicle in a more human-readable format, but the data from the vehicle is more difficult to understand or use. Normalization layer 220 may be included or excluded depending on the specific implementation of the layered API stack. Normalization layer 220 may include one or more elements (normalization layer elements 221-1, 221-2, ..., 221-N), which may be configured with different logic for handling different normalization processes.

[0040] As an example of using normalization layer 220, a brake caliper may have an interface in direct interface layer 250, and application 200 attempts to apply a braking force to the brake caliper. However, from application 200's perspective, it may be difficult to specify the exact force; rather, application 200 may simply quantify the braking force in terms of a percentage (0-100%, with 100% being the maximum amount of braking force applied and 0% being the minimum amount of braking force). It may not be necessary for application 200 to include a specific braking force. Thus, an element in normalization layer 220 (e.g., normalization layer element 221-1) may be used to convert a percentage from application 200 to a force value (e.g., Newtons) at a lower abstraction layer (such as direct interface layer 250). It should be understood that similar elements may be used to implement accelerator (percentage to acceleration actuation) or fan speed (percentage to PWM / voltage).

[0041] As another example of using normalization layer 220, the battery and fuel levels on a vehicle's dashboard (which may be controlled by a vehicle application) may typically be displayed as percentages, but sensors may detect voltage and volume, respectively. Thus, element 221-1 in normalization layer 220 may be used to convert from voltage / volume to percentage.

[0042] As another example of using normalization layer 220, images received at application 200 may be required to be of a particular size (e.g., 512x512 pixels) (e.g., for use with a convolutional neural network (CNN)). Meanwhile, images received from a camera as direct interface layer 250 may be received in a different format (e.g., 1024x768 pixels). Thus, element 221-1 in normalization layer 220 may crop the images received at direct interface layer 250, or in some cases, upscale the images from direct interface layer 250, and provide the processed images to application 200.

[0043] According to an embodiment, the signal validity layer 210 may be provided as an abstraction layer. The signal validity layer 210 may be intended to combine multiple received signal data from multiple signal sources (e.g., from the direct interface layer 250) and send a validity flag to at least one application 200 based on whether the combined multiple received signal data is valid. The signal validity layer 210 may be included or excluded depending on the specific implementation of the layered API stack. The signal validity layer 210 may comprise one or more elements (signal validity layer elements 211-1, 211-2, ..., 211-N) that may be configured with different logic for handling the signal validity verification process.

[0044] As an example of using the signal validity layer 210, a signal source (either directly from the interface layer 250 or from a lower abstraction layer) may provide an engine indicator signal, a brake light indicator signal, and a vehicle speed signal from a GPS. An element in the signal validity layer 210 (e.g., signal validity layer element 211-1) may check whether the indicator signals are on when the engine indicator signal is on and the vehicle speed signal indicates that the vehicle is not moving. If the brake light indicator signal is not on, the signal validity layer 210 may consider at least one of the data signals to be invalid and may send a validity flag (indicating whether the data signal is valid) to the application 200.

[0045] As another example of the use of the signal validity layer 210, the validity flag need not be a binary flag. For example, camera data can have multiple modality / status indicators, such as, but not limited to, “invalid,” “degraded,” “blocked,” or “functioning as expected.” For example, “invalid” may refer to invalid data, such as from a failed sensor, while “blocked” may refer to when the camera detects that nothing is visible. While data from a data signal may be considered unusable, the difference in the status indicator indicating a failed sensor or blocked camera may be useful to the application 200 to interpret for troubleshooting. “Degraded” may mean that current conditions (e.g., environmental conditions while operating the vehicle) make it difficult for the sensor to detect objects with complete reliability, but the data may not necessarily be simply released by the application 200. Thus, it should be understood that the validity flags used in the signal validity layer 210 may be able to indicate to the application 200 a wider range of conditions that may be useful for potential troubleshooting or decision-making by the application 200.

[0046] 3 is a block diagram illustrating an example implementation of a layered API stack in accordance with one or more example embodiments. In the illustrated example, application 300, normalization layer 310, processing / merging layer 320, unit conversion layer 330, and direct interface layer 340 are provided in layered API stack (which may correspond to application 200, normalization layer 220, processing / merging layer 230, unit conversion layer 240, and direct interface layer 250, as described in FIG. 2 above).

[0047] A direct interface layer 340 is provided, which collects wheel speed 341-1 and GPS speed 341-2 in ticks / s and kph, respectively, in a vehicle sensor specific format, and kgm / s 2 The brake controller 341 receives a command to activate the braking force (braking force 341-3) in a unique format.

[0048] The unit conversion layer 330 may convert ticks / s received at wheel speed 341-1 to m / s for element wheel speed 331-1, and similarly, the GPS speed 331-2 may convert kph received at GPS speed 341-2 to m / s and send them to the processing / fusion layer 320. The unit conversion layer 330 may also convert Newtons received from the normalization layer 310 (from deceleration force 311-1) using braking effort 331-3 and send them directly to braking effort 341-3 in the interface layer 340.

[0049] The processing / fusion layer 320 may receive two converted speed signals in the vehicle speed 331-1 (e.g., wheel speed 331-1 and GPS speed 331-2), determine which of the wheel speed 321-1 and the GPS speed 331-2 is more accurate, and then send the result to the application 300.

[0050] The normalization layer 310 can receive a ratio of the deceleration force from the application 200 (at element deceleration force 311-1) and convert that ratio to braking force in Newtons for transmission to braking force 331-3 in the unit conversion layer 330.

[0051] Although not shown in FIG. 3, it should be understood that a signal availability layer (such as signal availability layer 210) may also be included (e.g., directly below or above unit conversion layer 330). Furthermore, while the abstraction layers shown in FIG. 3 are arranged in a particular manner, it should be understood that in other implementations the abstraction layers may be rearranged, more processing / fusion layers 320 may be added, and some abstraction layers may be removed entirely.

[0052] FIG. 4 is a flowchart diagram illustrating a method 400 for translating sensor data received from a direct interface layer toward an application, according to one or more example embodiments.

[0053] In act S410, sensor data (or other data) may be received at a direct interface layer (such as direct interface layer 250, 340 as described above).

[0054] In act S420, the sensor data received in act S410 may be converted into a standardized format using elements in a unit conversion layer (such as unit conversion layer 240, 330, as described above).

[0055] In operation S430, the normalized sensor data from operation S420 may be processed into a format that may be usable by an application (such as application 200, 300, as described above). This may be performed by a higher abstraction layer, such as processing / fusion layer 230, 320 or normalization layer 220, 310, as described above.

[0056] FIG. 5 is a flowchart diagram illustrating a method 500 for translating application instructions directly to an interface layer, according to one or more exemplary embodiments.

[0057] At operation S510, data indicating instructions sent by an application (such as application 200, 300 as described above) may be received in a normalized data format at a normalization layer (such as normalization layer 220, 310 as described above).

[0058] In operation S520, elements in the normalization layer may convert the format of the instructions to a standardized format used by a unit conversion layer (such as unit conversion layer 240, 330 as described above).

[0059] In operation S530, an element of the unit conversion layer can convert the format of the instruction from the standardized format in operation S520 to a native format usable by the direct interface layer (such as the direct interface layer 250, 340 as described above).

[0060] In operation S540, the direct interface layer may relay the command to the appropriate vehicle element (e.g., if the command indicates applying a decelerating force, the direct interface layer may provide the appropriate braking force to the brake calipers).

[0061] FIG. 6 is a flowchart diagram illustrating a method 600 for using a signal availability layer, according to one or more exemplary embodiments.

[0062] In operation S610, one or more signals may be received from a direct interface layer (such as direct interface layer 250, 340 as described above).

[0063] In act S620, a signal validity layer (such as signal validity layer 210 described above) may process the signal received in act S610 to determine the validity of the data signal. According to an embodiment, the processing may include comparing one or more signals based on predetermined logic.

[0064] At operation S630, based on the result of operation S620, a validity flag may be sent to an application (such as application 200, 300 as described above). According to an embodiment, the validity flag may indicate binary validity (whether the data is valid or not). According to an embodiment, the validity flag may be a status indicator of the data and may further indicate whether the data is corrupted or blocked.

[0065] FIG. 7 is a flowchart diagram illustrating a method 700 for automatic Interface Description Language (IDL) file generation, according to one or more example embodiments.

[0066] According to an embodiment, one or more of the interfaces (e.g., hardware) or abstraction layers provided may be initially described in terms of a specification (e.g., a specification defined in a standard JSON format), while the API generated for each abstraction layer of the layered API may be an operation-specific Interface Description Language (IDL) file. Thus, the process defined in method 700 may be used to generate the appropriate abstraction layer.

[0067] In act S710, specifications for interfaces on the same abstraction layer may be combined.

[0068] In act S720, the file format of the combined specification from act S710 may be converted into an IDL native file format.

[0069] Based on the above, it can be seen that because the abstraction layer is distinct from the hardware layer (direct interface layer), software testing can be performed independently of the hardware. The overall complexity of vehicle applications can be simplified because what is received from the application is not affected by unit conversions or data processing that arise from hardware-specific configurations. Furthermore, the APIs for each layer have automatically generated code, further simplifying the amount of work required to be performed by software developers.

[0070] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the exemplary embodiment or embodiments to the precise forms disclosed. Modifications and variations are possible in light of the disclosure or may be acquired from practice of the exemplary embodiment or embodiments.

[0071] One or more exemplary embodiments may relate to a system, method, and / or computer-readable medium at any possible level of technical detail of integration. Furthermore, one or more of the components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium (or medium) having computer-readable program instructions for causing a processor to perform operations.

[0072] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory sticks, floppy disks, punch cards or mechanically encoded devices such as slotted structures having instructions recorded thereon, and any suitable combination of the above. Computer-readable storage medium, as used herein, should not be construed as being a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0073] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0074] The computer-readable program code / instructions for carrying out operations may be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++®, and procedural programming languages ​​such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In one or more exemplary embodiments, an electronic circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuit to perform an aspect or operation.

[0075] These computer-readable program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer-readable program instructions can also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that a computer-readable storage medium having instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0076] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to generate a computer-implemented process that executes on the computer, other programmable data processing apparatus, or other device a series of operational steps that are performed on the computer, other programmable data processing apparatus, or other device such that the instructions, executing on the computer, other programmable data processing apparatus, or other device, implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0077] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible exemplary embodiments of systems, methods, and computer-readable media according to one or more exemplary embodiments. In this regard, each block in the flowcharts or block diagrams may represent a microservice, module, segment, or portion of an instruction set, comprising one or more executable instructions for implementing the specified logical function(s). The methods, computer systems, and computer-readable media may include additional, fewer, different, or arranged differently from that depicted in the figures. In one or more alternative exemplary embodiments, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be executed concurrently or substantially concurrently, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs specified functions or acts or executes a combination of special-purpose hardware and computer instructions.

[0078] It will be apparent that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and / or methods does not limit one or more embodiments. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. An apparatus for providing an interface for a vehicle application, comprising: a memory for storing instructions; a direct interface layer having at least one signal source; a unit conversion layer configured to receive signal data from at least one of the signal sources and convert the signal data into a standardized format; a processing layer configured to process the converted signal data from the unit conversion layer into processed signal data that can be interpreted by at least one application; at least one processor configured to execute the instructions to provide a layered application programming interface (API), An apparatus having:

2. 2. The apparatus of claim 1, wherein the layered API further comprises a normalization layer that normalizes the converted signal data from the unit conversion layer into normalized signal data that is sent to the at least one application.

3. The apparatus of claim 2 , wherein the normalized signal data comprises a ratio.

4. 3. The apparatus of claim 2, wherein the transformed signal data includes an image at a first magnitude and the normalized signal data includes an image at a second magnitude different from the first magnitude.

5. The layered API includes: combining a plurality of received signal data from a plurality of said signal sources; transmitting a validity flag to the at least one application based on determining validity of the combined plurality of received signal data.

5. The device of claim 1, further comprising a signal effectiveness layer configured to:

6. The apparatus of claim 5 , wherein the validity flag indicates whether the received signaling data is valid.

7. The apparatus of claim 6 , wherein the validity flag further indicates whether the received signal data is corrupted or blocked.

8. 1. A method for providing an interface for a vehicle application, comprising: receiving, by a unit conversion layer of a layered application programming interface (API), signal data from at least one signal source of a direct interface layer of the layered API; converting the received signal data into converted signal data in a standardized format by the unit conversion layer; processing the converted signal data by a processing layer of the layered API into processed signal data that can be interpreted by at least one application; The method is performed by a processor.

9. normalizing the transformed signal data into normalized signal data by a normalization layer of the layered API; transmitting, by the normalization layer, the normalized signal data to the at least one application; The method of claim 8 further comprising:

10. The method of claim 9 , wherein the normalized signal data comprises a ratio.

11. 10. The method of claim 9, wherein the transformed signal data comprises an image at a first magnitude and the normalized signal data comprises an image at a second magnitude different from the first magnitude.

12. combining, via a signal validity layer of the layered API, a plurality of received signal data from a plurality of said signal sources; and transmitting a validity flag to the at least one application based on determining validity of the combined plurality of received signal data by the signal validity layer. The method of any one of claims 8 to 11, further comprising:

13. The method of claim 12 , wherein the validity flag indicates whether the received signaling data is valid.

14. The method of claim 13 , wherein the validity flag further indicates whether the received signaling data is corrupted or blocked.

15. receiving, by a unit conversion layer of a layered application programming interface (API), signal data from at least one signal source of a direct interface layer of the layered API; converting the received signal data into converted signal data in a standardized format by the unit conversion layer; processing the converted signal data by a processing layer of the layered API into processed signal data that can be interpreted by at least one application; A computer program that causes a processor to perform a process including:

16. The process comprises: normalizing the transformed signal data into normalized signal data by a normalization layer of the layered API; transmitting, by the normalization layer, the normalized signal data to the at least one application; The computer program of claim 15 , further comprising:

17. The computer program of claim 16 , wherein the normalized signal data comprises a ratio.

18. 17. The computer program of claim 16, wherein the transformed signal data comprises an image at a first magnitude and the normalized signal data comprises an image at a second magnitude different from the first magnitude.

19. The process comprises: combining, via a signal validity layer of the layered API, a plurality of received signal data from a plurality of said signal sources; and transmitting a validity flag to the at least one application based on determining validity of the combined plurality of received signal data by the signal validity layer. The computer program according to any one of claims 15 to 18, further comprising:

20. 20. The computer program product of claim 19, wherein the validity flag indicates whether the received signal data is valid.

Images