CN113608738B - Automobile service system based on someip instrument data - Google Patents
Automobile service system based on someip instrument data Download PDFInfo
- Publication number
- CN113608738B CN113608738B CN202110848669.6A CN202110848669A CN113608738B CN 113608738 B CN113608738 B CN 113608738B CN 202110848669 A CN202110848669 A CN 202110848669A CN 113608738 B CN113608738 B CN 113608738B
- Authority
- CN
- China
- Prior art keywords
- service
- data
- module
- tool
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000004891 communication Methods 0.000 claims abstract description 30
- 230000005540 biological transmission Effects 0.000 claims description 11
- 239000003795 chemical substances by application Substances 0.000 claims description 10
- 239000004973 liquid crystal related substance Substances 0.000 claims description 6
- 238000011161 development Methods 0.000 claims description 5
- 230000002093 peripheral effect Effects 0.000 claims description 5
- 238000007726 management method Methods 0.000 claims description 4
- 238000012790 confirmation Methods 0.000 claims description 3
- 230000003993 interaction Effects 0.000 claims description 3
- 230000004044 response Effects 0.000 claims description 3
- 238000013524 data verification Methods 0.000 claims description 2
- 238000009432 framing Methods 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 8
- 238000000034 method Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 239000011800 void material Substances 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 238000009434 installation Methods 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 230000000007 visual effect Effects 0.000 description 2
- 230000002776 aggregation Effects 0.000 description 1
- 238000004220 aggregation Methods 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000005315 distribution function Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/38—Creation or generation of source code for implementing user interfaces
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60K—ARRANGEMENT OR MOUNTING OF PROPULSION UNITS OR OF TRANSMISSIONS IN VEHICLES; ARRANGEMENT OR MOUNTING OF PLURAL DIVERSE PRIME-MOVERS IN VEHICLES; AUXILIARY DRIVES FOR VEHICLES; INSTRUMENTATION OR DASHBOARDS FOR VEHICLES; ARRANGEMENTS IN CONNECTION WITH COOLING, AIR INTAKE, GAS EXHAUST OR FUEL SUPPLY OF PROPULSION UNITS IN VEHICLES
- B60K35/00—Arrangement of adaptations of instruments
-
- B60K35/22—
-
- B60K35/265—
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/40—Transformation of program code
- G06F8/41—Compilation
- G06F8/44—Encoding
- G06F8/447—Target code generation
Abstract
The invention relates to the technical field of automobile instruments, and aims to provide an automobile service system based on the data of a someip instrument, which comprises a tool module, a service class module, an application class module, a basic module and a service class configuration file module, wherein the tool module comprises a first tool, a second tool and a third tool, the first tool and the second tool are used for generating general classes and interfaces, and the third tool is used for generating the classes and interfaces of the service class module; the service class module comprises a first service, a second service and a third service, wherein the first service and the second service are used for collecting data of the bottom MCU, and the third service is used for writing a back-end library; the application module comprises an HMI display module, a HUD display module, an animation module and a sound player; the basic module comprises a boost, a vsomeip and a common api, and the soleip is selected as a bottom communication module which is specially designed for automobile electronics and is suitable for single-node internal communication or multi-node communication.
Description
Technical Field
The invention relates to the technical field of automobile instruments, in particular to an automobile service system based on someip instrument data.
Background
With the rapid development of automobile electronic and electric technologies, people hope to obtain more and more visual presentation effects. Liquid crystal digital instruments of automobiles meet the demands of people. It brings us with it very much more convenient and useful information about the driving experience. The driver can obtain the desired information through vivid animation, not limited to the conventional LCD lamp. The automobile liquid crystal digital instrument platform software provides various additional information, and is suitable for more scenes through an extensible software architecture.
The whole structure of the current automobile liquid crystal digital instrument is that an SOC and an MCU are coordinated, the SOC is responsible for all general operation and image processing, and the MCU is responsible for overview of data on all buses and reporting to the SOC in a summarizing way. In addition to the data from the MCU, many of the information from the IVI also needs to be received by the digital instrument to get a better user experience, forming a variety of data sources. The HMI program responsible for the main logic processing must acquire data from multiple places, which causes problems related to communication to be handled in addition to the display logic itself, resulting in increased software complexity and reduced quality.
This requires a special data service center to fuse all the data sources. At present, for the convenience of application development, the native inter-process communication mode of an operating system is not used in a software architecture, but is a basic middleware based on the communication mode. Currently, D-BUS is mainly used, and based on the architecture mode with a distribution center, the communication efficiency is low, and the main design is designed for a desktop, so a new data processing system capable of improving the communication efficiency is needed.
Disclosure of Invention
The invention aims to overcome the defects of the prior art and provide an automobile service system based on the someip instrument data, wherein a data service module adopts someip as a bottom communication module, and the module is specially designed for automobile electronics and is suitable for single-node internal communication or multi-node communication.
The method is realized by the following technical scheme: the automobile service system based on the someip instrument data comprises a tool module, a service class module, an application class module, a base module and a service class configuration file module,
the tool module comprises a first tool, a second tool and a third tool, wherein the first tool and the second tool are used for generating general classes and interfaces, and the third tool is used for generating the classes and interfaces of the service class module;
the service class module comprises a first service, a second service and a third service, wherein the first service and the second service are used for collecting data of the bottom MCU, and the third service is used for writing a back-end library;
the application module comprises an HMI display module, a HUD display module, an animation module and a sound player;
the basic module comprises a boost, a vsomeip and a common api, wherein the boost is mainly used by the vsomeip, and the common api unifies a special vsomeip interface into a fixed interface;
the service profile module comprises ipc_sheet. Xls, hmi_server. Fidl and hmi_server. Fdepl, wherein ipc_sheet. Xls, ipc_sheet. Xls are used for defining the data types related to specific services in the first service, and generating files through a third tool, and hmi_server. Fidl and hmi_server. Fdepl are respectively used for configuring parameters of a service interface, a signal and a transmission layer.
Preferably, the first tool, the second tool and the third tool are a common-generator-linux-x86_64, a common-generator-linux-x86_64 and a generator-ipc-header, respectively, which are tools of the first service ipc data server responsible for generating classes and interfaces of the first service ipc data server, and enumeration and structure definition thereof.
Preferably, the first service, the second service and the third service are respectively ipc_data_server, hmi_server and libspipic, wherein the hmi_server comprises a proxy manager for managing client agents of a plurality of communication parties, and simultaneously provides a unified service for external use.
Preferably, the libspipic is used as a communication back end and is responsible for communicating with the MCU and obtaining data on a bottom bus, and besides basic communication capability, the libspipic core module further comprises a frame splicing module, a frame decoding module, a data checking module and a virtual channel, the libspipic core module is divided into a base module, a core module and a bottom module, the base module comprises three implementation channels, namely, queue event implementation of queue, pipe event implementation based on pipe and socket event implementation based on socket.
Preferably, the bottom layer module is a SPI hardware peripheral, and the SPI-based protocol requires two hard wires for data request and confirmation, and requires a GPIO to complete data response.
Preferably, the core module includes Resmgr and a handler, resmgr being used to implement virtual channels.
Preferably, the MCU data service center is the ipc_data_server of the first service, where the ipc_data_server is composed of a general code and an application class code, the general code remains unchanged, and the application code is generated by a tool, and the basic development flow includes the following steps:
s71, manually converting the user requirement into an ipc_sheet.xls file, and defining a transmission period, a transmission type and a data identification of the data;
s72, generating a file, command_definitions_map.h, data_server_image.h, message_definitions_map.h, video_message_definitions_map.h and a fidl file by using a tool generate_ipc_header;
and S73, compiling the general codes and the generated codes to generate the ipc_data_server.
Preferably, the ipc_data_server comprises a main function, a data frame manager, a command manager, a message manager, a service interface and a driver management.
The automobile service system based on the someip instrument data is used for the purposes of liquid crystal digital instruments and human-computer interaction interfaces.
The beneficial effects of the invention are as follows:
(1) The automobile liquid crystal digital instrument platform software provides various additional information, and is suitable for more scenes through an extensible software architecture;
(2) Is suitable for single-node internal communication or multi-node communication.
Drawings
FIG. 1 is an overall system block diagram of the present invention;
FIG. 2 is a schematic diagram illustrating the operation of the ipc_data_server according to an embodiment of the present invention;
FIG. 3 is a diagram of an ipc_data_server composition in one embodiment of the present invention;
FIG. 4 is a schematic diagram of an automatic distribution of ipc_data_server in accordance with an embodiment of the present invention;
FIG. 5 is a diagram of a Hmi _server composition according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of client grouping and installation in accordance with one embodiment of the present invention;
FIG. 7 is a diagram showing the composition of a communication backend libspiip in one embodiment of the present invention
Fig. 8 is a schematic diagram of a core module according to an embodiment of the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings 1 to 8, in which it is evident that the embodiments described are only some, but not all embodiments of the present invention. Based on the embodiments of the present invention, one of ordinary skill in the art would obtain all other implementations that may be obtained without undue burden.
In the description of the present invention, it should be understood that the terms "counterclockwise," "clockwise," "longitudinal," "transverse," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," "outer," and the like indicate orientations or positional relationships based on the orientation or positional relationships shown in the drawings, are merely for convenience in describing the present invention, and do not indicate or imply that the devices or elements referred to must have a specific orientation, be configured and operated in a specific orientation, and therefore should not be construed as limiting the present invention.
Examples:
referring to FIG. 1, the modules involved are divided into five broad categories, wherein common-generator-linux-x86_64 and common-sole-generator-linux-x86_64 are tools in the base module responsible for generating generic classes and interfaces, and generate_ipc_header is a tool for ipc_data_server responsible for generating enumeration and structure definition of ipc_data_server, and other application modules.
The service class is a core part, please refer to fig. 2 and 3, and the ipc_data_server and the hmi_server are composed of two application programs. The IPc_data_server is responsible for data collection from the bottom MCU, the module codes of the IPc_data_server are divided into general codes and data related to specific services, the specific related service data codes can be generated through the generation_ipc_header file without manual writing, meanwhile, the IPc_data_server is also responsible for loading a back-end library of IPC communication, libspin is a back-end based on a spi peripheral, and other back-end libraries can be written. In addition to the data from mcu, some data may come from ivi, etc., and the communication mode may be various, so there is a service to mask the difference between communication partners, which is a proxy manager of hmi_server, for managing client agents of multiple communication partners, and at the same time, providing a unified service to external use.
The application class part is various applications, and includes HMI display program, HUD display program, automatic test program, etc. of specific service. They have the same position and can interact with the hmi_server or the ipc_data_server indiscriminately.
The basic module comprises a boost, a vsomeip and a common api, wherein the boost is mainly used by the vsomeip, and the common api unifies the special vsomeip interface into a fixed interface, which also leads to the fact that the special vsomeip interface can support other underlying communication modes, such as DBUS, DDS and the like.
Configuration files mainly comprise three types, namely, the ipc_sheet. Xls is used for defining the data types related to specific services in the ipc_data_server, and after application data are matched in the ipc_sheet, a series of files needing to be used can be generated through generating_ipc_header. The other two configuration files are used for the hmi_server to configure the service interface and the signal, and parameters of the transmission layer respectively.
Libsplipic is a communication back-end, and is responsible for communicating with the MCU and obtaining data on the underlying bus, and has framing, deframeing, data verification, virtual channels, etc. in addition to basic communication capabilities, referring to FIG. 7. libspipic provides the following interface for ipc_data_server to use:
int32_t init_drv(int32_t*argc,char**argv)
int32_t receive_drv_resmgr_frame(int32_t*channel_id,uint8_t*app_data,int32_t*size)
int32_t send_drv_resmgr_frame(int32_t channel_id,uint8_t*app_data,int32_t size)
void cleanup_drv_resmgr(void)
these interfaces are general interfaces of the abstract ipc_data_server back-end, and any other interfaces can be used as the back-end as long as the interfaces are provided.
Other core implementations are completed in a libspipic core, and the libspipic core module is divided into a base module, a core module and a bottom layer module.
Some foundations are packaged in the foundation module to be more beneficial to modularized programming, and three implementations are supported in a channel of the foundation module at present, namely, the implementation of the queue event based on the queue, the implementation of the pipe event based on the pipe and the implementation of the socket event based on the socket. It can implement channel by configuring the selection, currently selecting by default the socket event in socket.
The bottom layer module mainly uses the spi hardware peripheral equipment, is universal, is abstracted into a communication hal device, and the hal device calls the spi interface to complete receiving and transmitting of bottom layer data, and of course hal can be adjusted to support other peripheral interfaces, such as UART. At present, two hard wires are needed to be used as data request and confirmation, and the response of data is needed to be completed through GPIO, so that the operation on the GPIO is also realized in hal.
The core module consists of two parts: resmgr and handler, resmgr being the place where the virtual channel is implemented, as shown in fig. 8, the frame format written by the master device:
table 1 example of frame format written by master device
Table 2 frame format read by master device
The current frame is transmitted in a fixed frame format at the bottom layer, the format of which is shown in fig. 8, wherein the length calculation formula is as follows,
total length = message 1 length + message 2 length + … + message N length +4 (CRC check length) inside each fixed frame, multiple messages may be contained. The format of each message is as follows:
table 3 message formats within fixed frames
The ipc_data_server consists of a generic code and an application class code, the generic code remains unchanged, and the application code is generated by a tool. The basic development flow is as follows:
step 1: the user needs are manually converted into an ipc_sheet.xls file, and the transmission period, the transmission type and the data identification of the data are defined.
Step 2: the ipc_sheet. Xls is used to generate files, command_definitions_map. H, data_server_image. H, message_definitions_map. H, visual_message_definitions_map. H, and fidl files using the tool generate_ipc_header.
Step 3: compiling the universal code and the generated code to generate the ipc_data_server.
Since the ipc_data_server needs to provide a service interface based on a someip, a fidi file is also needed, and the content is related to specific application data, so the fidi file must also be generated by a tool, and an example of the generation is as follows: ipc_data_server.fidl example file:
the main modules and the main tasks thereof in the ipc_data_server module are shown above. In addition to the main function, the ipc_data_server consists of the following main modules: data frame manager, command manager, message manager, service interface and driver management.
The main function is the entry point of the ipc_data_server, which first establishes the basic operating environment, such as resolution of options, print message level processing, setting of environment variables. When this is done, a driver manager is instantiated, which functions to expose the driver's interface to ipc_data_server for use according to the option parameters. The interface prototype is as follows:
typedef int32_t(*DrvInit)(int32_t*argc,char**argv)；
typedef int32_t(*DrvReceive)(int32_t*channel_id,uint8_t*app_data,int32_t*size)；
typedef int32_t(*DrvSend)(int32_t channel_id,uint8_t*app_data,int32_t size)；
typedef void(*DrvCleanup)(void)；
these are universal prototype interfaces, do not distinguish the actual physical communication interfaces of the bottom layer, the purpose of this design is to conveniently load different drive back ends, only realize the back end drive based on SPI at present, other interface back ends can also support, only need to provide the same drive interface to ipc_data_server. After the loading and the realization of the drive are completed, the data frames from the MCU can be received. The current libspiipc.so already has the ability to spell and defrag frames, so the data arriving at the ipc_data_server is already the original message after defragmentation.
Table 4 format of original message
The current support characteristic functions have the following paths:
there are only three types of data sent from the MCU to the SOC: ipc_feed_ioc_ntf, ipc_feed_ioc_req, ipc_feed_ioc_rep.
The IPC_FEATURE_IOC_NTF and IPC_FEATURE_IOC_REQ carry valid data, and the purpose of the IPC_FEATURE_IOC_REP is only to confirm that the MCU has received data sent by the SOC. The data supported by ipc_feed_ioc_ntf is periodic data, and because of this FEATURE, the SOC does not need to acknowledge back it, but ipc_feed_ioc_req requires the SOC to acknowledge back after receiving, and the serial number of the reply must be the same as the serial number received. The following is the message splitting. The automatic distribution adopts an automatically generated message distribution function with the function ID as an index. As shown in fig. 4.
If the client reads the signal, the message is delivered to the client. Clients that do not subscribe to the message will not receive the message.
The same is that the ipc_data_server has a caching mechanism, i.e. if no client is online, if a message is sent out from the bottom layer, the service will cache the latest state of different messages, and this mechanism is to solve the problem that if some messages are non-periodic information, but the client is not online yet, the message comes, resulting in message loss.
One type of message is called a small message, and the type of message is a delivery alarm type, and is as follows:
such messages integrate the indicator lights, popup and sound in the alarm into one small message, but the reliable transmission (with acknowledgement mechanism, if the data are the same, the application layer will not be reported) used in the message transmission layer, and in order to save the data bandwidth, multiple small messages may be included in one packet of data. Thus, the entire packet is to be unwound for smallmessage type messages in the ipc_data_service. To achieve this, a small message aggregation table is added. The smallmessage for the same ID will be stored for the last time. So as to ensure that the latest information can be received when different clients are online.
In practice there is another case where the message is an event type message, there is no last value, and the message is not stored. Another message is defined for this purpose, called a visual message, such as a key press operation, which is triggered by a mistake if the store is on-line when a new client is on-line.
Comprehensive data service center hmi_server:
there are various sources of current data, and the ipc_data_server currently centrally processes data from mcu. But the data from ivi or hud also needs to be managed. There is a so-called integrated data service center module hmi_server that manages part of the data of ipc_data_server, and also manages all other data. For hmi, only interaction with hmi_server is needed to get all the data.
Other ancillary modules and specific business modules are removed, as in fig. 5, leaving only the modules associated with the data services. The method is mainly divided into two parts:
the core module comprises:
proxy agent-one agent is required for each data service locally, and Proxy agent manages all agents. Including agents for data services, as well as agents based on its specific traffic. Such as a boot animation agent, a sound player agent, etc.
Message all data coming from outside is treated as one Message, the types of the messages can be various, the structure is provided, the original byte stream is provided, and the small Message is provided. Message management manages all messages.
Signal message data reported to the application layer at the back end are called signals, and are converted into signals when data messages are sent.
Configuration file:
mainly, a data service interface is provided, and the configuration files are as follows:
/>
/>
because of the large number of signals, the client only cares about the signals of own interest, so the signals are converted into a unified structure at this layer, as follows:
meanwhile, the client needs to tell the hmi_server of the signal concerned by itself through the setSignalfilters interface, and only receives a specific signal. To distinguish between different signals, the signals have unique IDs to identify them. The signals are currently divided into packets with a maximum number of signals supported by each packet of 2000.
/>
The commands sent by the same client are also grouped, and the grouping situation is as follows, and the maximum number of commands supported by each command group is 200:
the same messages are also grouped, and the current grouping and installation mode is as shown in fig. 6, and the maximum message number supported by each group is 256:
because the bottom layer of the data service module adopts a software form, a cmake compiling mode is adopted, and the mode supported by the internal compiling system at present is makefile and shell script, so the mode supported by the cmake is realized through the shell script.
Firstly, building.sh and CMakeList.txt files need to be written in the module, and the form is as follows:
the build. Sh part example is that,
/>
/>
/>
/>
/>
after the build. Sh and cmakelist. Txt files are written, they need to be added to the compiling system, each project has a special configuration file env_setup. Py, the following is added to the module_configuration of the file, note that the build_sys must select build, so that the MODULE is already added to the compiling system, and when the whole project is compiled, the MODULE is compiled.
{'module_name':'hmi_server','workspace_path':'hmi_server','copyfiles_config':'tcfg_app/HmiServer.txt','build_sys':'build'}
It is worth noting that the environment of the software is Boost > =1.55, c++11 standard, GCC > =4.8, the rake compilation system >2.8.12, the vsome module, the Common API module.
In summary, according to the embodiment, based on the automobile instrument display system, the data is integrated and processed, and the integrated system is not limited to the unilateral data of the MCU, and the information of a plurality of data sources is fused, so that the novel universal system based on the someip as the bottom communication module is obtained by using the above overall architecture.
Claims (6)
1. The automobile service system based on the someip instrument data is characterized by comprising a tool module, a service class module, an application class module, a basic module and a service class configuration file module,
the tool module comprises a first tool, a second tool and a third tool, wherein the first tool and the second tool are used for generating general classes and interfaces, and the third tool is used for generating the classes and interfaces of the service class module;
the service class module comprises a first service, a second service and a third service, wherein the first service and the second service are used for collecting data of the bottom MCU, and the third service is used for writing a back-end library;
the application module comprises an HMI display module, a HUD display module, an animation module and a sound player;
the basic module comprises a boost, a vsomeip and a common api, wherein the boost is mainly used by the vsomeip, and the common api unifies a special vsomeip interface into a fixed interface;
the service profile module comprises ipc_sheet. Xls, hmi_server. Fidl and hmi_server. Fdepl, which are used for defining the data types related to specific services in the first service, and generating a file through a third tool, wherein the hmi_server. Fidl and the hmi_server. Fdepl are respectively used for configuring parameters of a service interface, a signal and a transmission layer;
the first service, the second service and the third service are respectively ipc_data_server, hmi_server and libspipic, wherein the hmi_server comprises a proxy manager for managing client agents of a plurality of communication parties and simultaneously providing a unified service for external use;
the libspipic is used as a communication back end and is responsible for communicating with the MCU and obtaining data on a bottom bus, and besides basic communication capability, the libspipic also has frame splicing, frame de-framing, data verification and virtual channels; the MCU data service center is the ipc_data_server of the first service, the ipc_data_server consists of a universal code and an application class code, the universal code is kept unchanged, the application code is generated by a tool, and the basic development flow comprises the following steps:
s71, manually converting the user requirement into an ipc_sheet.xls file, and defining a transmission period, a transmission type and a data identification of the data;
s72, generating a file command_definitions_map.h, a data_server_image.h, a message_definitions_map.h, a video_message_definitions_map.h and a fidl file by using a tool generate_ipc_header;
s73, compiling the general code and the generated code to generate an ipc_data_server;
the first tool, the second tool and the third tool are respectively a common-generator-linux-x86_64, a common-sol-generator-linux-x86_64 and a generator_ipc_header, wherein the generator_ipc_header is a tool of the first service ipc_data_server and is responsible for generating classes and interfaces of the first service ipc_data_server, enumeration and structure definition of the classes and interfaces.
2. The automobile service system based on the someip instrument data according to claim 1, wherein the libspipic is divided into a base module, a core module and a bottom module, and the base module comprises three implementation channels, namely a queue event implementation of queue, a pipe event implementation of pipe and a socket event implementation of socket.
3. The vehicle service system based on someip meter data according to claim 2, wherein the bottom module is a SPI hardware peripheral, and the SPI-based protocol requires two hard wires for data request and confirmation, and requires a GPIO to complete a data response.
4. The vehicle service system based on someip meter data of claim 2, wherein the core module includes Resmgr and handler, and Resmgr is used to implement virtual channels.
5. The vehicle service system based on someip meter data according to claim 1, wherein the ipc_data_server comprises a master function, a data frame manager, a command manager, a message manager, a service interface, and a driver management.
6. Use of a vehicle service system based on someip meter data according to any one of claims 1 to 5 for a liquid crystal digital meter, a human-computer interaction interface.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110848669.6A CN113608738B (en) | 2021-07-23 | 2021-07-23 | Automobile service system based on someip instrument data |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110848669.6A CN113608738B (en) | 2021-07-23 | 2021-07-23 | Automobile service system based on someip instrument data |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113608738A CN113608738A (en) | 2021-11-05 |
| CN113608738B true CN113608738B (en) | 2023-12-12 |
Family
ID=78305496
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110848669.6A Active CN113608738B (en) | 2021-07-23 | 2021-07-23 | Automobile service system based on someip instrument data |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113608738B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112612466A (en) * | 2020-12-22 | 2021-04-06 | 成都航盛智行科技有限公司 | Data exchange system and method of automobile display equipment based on IPC model |
| CN114817018B (en) * | 2022-04-18 | 2023-02-21 | 润芯微科技(江苏)有限公司 | Development and test system of instrument domain man-machine interaction standardized platform |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2019123447A1 (en) * | 2017-12-24 | 2019-06-27 | Arilou Information Security Technologies Ltd. | System and method for tunnel-based malware detection |
| CN112333662A (en) * | 2020-10-27 | 2021-02-05 | 浙江吉利控股集团有限公司 | V2X communication system and communication method |
| CN112748908A (en) * | 2020-12-31 | 2021-05-04 | 广东广宇科技发展有限公司 | Restful service development method and device based on SSM framework |
| CN112769767A (en) * | 2020-12-23 | 2021-05-07 | 华人运通(上海)云计算科技有限公司 | Vehicle-mounted Ethernet SOME/IP protocol data analysis method, device, medium and system |
| CN112804249A (en) * | 2021-01-28 | 2021-05-14 | 中汽创智科技有限公司 | Data communication method and system for remotely calling automatic driving platform |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11538287B2 (en) * | 2019-09-20 | 2022-12-27 | Sonatus, Inc. | System, method, and apparatus for managing vehicle data collection |
| US11683369B2 (en) * | 2019-11-21 | 2023-06-20 | Nxp Usa, Inc. | System for centralized data collection in a distributed service-oriented system |
-
2021
- 2021-07-23 CN CN202110848669.6A patent/CN113608738B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2019123447A1 (en) * | 2017-12-24 | 2019-06-27 | Arilou Information Security Technologies Ltd. | System and method for tunnel-based malware detection |
| CN112333662A (en) * | 2020-10-27 | 2021-02-05 | 浙江吉利控股集团有限公司 | V2X communication system and communication method |
| CN112769767A (en) * | 2020-12-23 | 2021-05-07 | 华人运通(上海)云计算科技有限公司 | Vehicle-mounted Ethernet SOME/IP protocol data analysis method, device, medium and system |
| CN112748908A (en) * | 2020-12-31 | 2021-05-04 | 广东广宇科技发展有限公司 | Restful service development method and device based on SSM framework |
| CN112804249A (en) * | 2021-01-28 | 2021-05-14 | 中汽创智科技有限公司 | Data communication method and system for remotely calling automatic driving platform |
Non-Patent Citations (3)
| Title |
|---|
| A Domain-Specific Language Based Architecture Modeling Approach for Safety Critical Automotive Software Systems;Stefan Schlichthärle等;Conference: 17th Workshop on Automotive Software Engineering;第1-6页 * |
| 基于SOME/IP协议的车载以太网摄像头模块研究与设计;鲁勋豪;中国优秀硕士学位论文全文数据库 工程科技Ⅱ辑(第2期);C035-280 * |
| 智能网联汽车电子电气架构设计与试验研究;邓戬;中国优秀硕士学位论文全文数据库 工程科技Ⅱ辑(第3期);C035-199 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113608738A (en) | 2021-11-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN113608738B (en) | Automobile service system based on someip instrument data | |
| EP1774755B1 (en) | Method and apparatus for enabling discovery and use of a service by a client device | |
| US8229998B2 (en) | Open interface device and method | |
| US8452903B2 (en) | Mobile computing device capabilities for accessories | |
| JP2000289583A (en) | Method and system for executing vehicle diagnosis | |
| JP2008522503A (en) | Digital data interface device message format | |
| JP7041285B2 (en) | Hosts that communicate with the FPGA, methods of communicating with the FPGA, and communication systems | |
| US7861221B2 (en) | Method and system for generating a source code for a computer program | |
| CN109933442A (en) | The means of communication, equipment and computer storage medium between small routine platform | |
| WO2020177697A1 (en) | Method for discovery between mini program platforms, device, and computer storage medium | |
| CN116775392A (en) | Chip communication testing method and device, electronic equipment and storage medium | |
| CN112511636B (en) | Data transmission system, method, device, computer equipment and storage medium | |
| WO2021169369A1 (en) | Data transmission method, apparatus and system | |
| WO2021088772A1 (en) | Method and apparatus for sending information in live broadcast room, and electronic device | |
| CN111708568B (en) | Modularized development decoupling method and terminal | |
| CN112367362A (en) | Data processing method, device and equipment and computer storage medium | |
| CN112688863B (en) | Gateway data processing method and device and electronic equipment | |
| EP4293974A1 (en) | Network configuration method, electronic device, and computer-readable storage medium | |
| CN112527422A (en) | View updating method, device, equipment and storage medium | |
| WO2024077937A1 (en) | Data generation method and apparatus, electronic device, and storage medium | |
| CN117812099A (en) | Data display method, vehicle-mounted system, vehicle and storage medium | |
| CN115801625A (en) | Network card forwarding performance test method, test terminal and server terminal | |
| CN117971351A (en) | Vehicle service function mapping and calling method, device, medium and equipment | |
| CN115714843A (en) | Communication system and communication method for receiving card of display device | |
| CN115826981A (en) | Real-time operating system driver adaptation method and device, electronic equipment and readable medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |