CN112532583A - Method for realizing service under CAN bus environment - Google Patents
Method for realizing service under CAN bus environment Download PDFInfo
- Publication number
- CN112532583A CN112532583A CN202011187919.8A CN202011187919A CN112532583A CN 112532583 A CN112532583 A CN 112532583A CN 202011187919 A CN202011187919 A CN 202011187919A CN 112532583 A CN112532583 A CN 112532583A
- Authority
- CN
- China
- Prior art keywords
- frame
- service
- data
- receiving
- obj object
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 26
- 238000013507 mapping Methods 0.000 claims description 4
- 238000012545 processing Methods 0.000 claims description 3
- 230000005540 biological transmission Effects 0.000 abstract description 4
- 238000004891 communication Methods 0.000 abstract description 4
- 239000000725 suspension Substances 0.000 abstract 1
- 238000006243 chemical reaction Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000012856 packing Methods 0.000 description 1
- 238000012827 research and development Methods 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/08—Protocols for interworking; Protocol conversion
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/544—Buffers; Shared memory; Pipes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5046—Resolving address allocation conflicts; Testing of addresses
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/50—Address allocation
- H04L61/5092—Address allocation by self-assignment, e.g. picking addresses at random and testing if they are already in use
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/54—Indexing scheme relating to G06F9/54
- G06F2209/548—Queue
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/40—Bus networks
- H04L2012/40208—Bus networks characterized by the use of a particular bus standard
- H04L2012/40215—Controller Area Network CAN
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
A method for realizing service under the CAN bus environment comprises the following steps: step 100, a client applies for a CAN _ OBJ object from an idle linked list, sets object attributes, sets the object state as 'use', points to a cache queue through a receiving address, and puts a service inquiry calling frame into a sending cache queue; step 200, a client sends a cache queue to wait for receiving and sending tasks, and when data is put in, the data is sent; step 300, the server receives the information of waiting for inquiry or calling of the suspension of the cache queue; step 400, after receiving the calling frame, the client sends a message to a receiving cache queue according to a positioning CAN _ OBJ object in the query return frame and a receiving address, and wakes up a calling thread; and 500, releasing the CAN _ OBJ object, putting the CAN _ OBJ object back to the tail part of the idle linked list, and deleting the receiving buffer queue. The invention improves the communication transmission capability and effectively supports the service with lower requirement on time delay.
Description
Technical Field
The invention belongs to the field of service calculation, and particularly relates to a method for realizing service under a CAN bus environment.
Background
Since the concept of the "internet of things" now called the EPC system was creatively proposed by the american academy of technology, national institute of technology, ma 1998, the internet of things is considered to be the third revolution of the information technology industry, with more and more developed countries and regions serving as one of the strategic high points of future development. Along with the popularization of the related technology of the internet of things, the research and development and the deployment of related intelligent embedded equipment, more and more fields such as intelligent automobiles, intelligent agriculture, intelligent logistics and the like are produced.
In the subject, the realization of the micro-service architecture is applied to the project of the intelligent automobile, the internal modules of the intelligent automobile realize data exchange through a CAN bus protocol, and different modules support single and tiny functions, are mutually independent and CAN support independent development. And the intelligent automobile internal module can remotely call the service outside the automobile.
However, there are also some problems in smart car design: at present, the communication transmission capacity of a CAN bus channel is still about 1Mbps, the CAN bus cannot better support the service with lower requirement on time delay, the CAN bus is not compatible with a TCP/IP protocol due to the characteristics of the protocol of the CAN bus, and the maximum value of the length data field length of a CAN bus protocol message is 8 bytes.
Disclosure of Invention
In order to overcome the defects of the prior art, the invention provides a method for realizing the service under the CAN bus environment, which improves the communication transmission capability and effectively supports the service with lower time delay requirement.
The technical scheme adopted by the invention for solving the technical problems is as follows:
a method for realizing service under the CAN bus environment comprises the following steps:
step 100, a client applies for a CAN _ OBJ object from an idle linked list, sets object attributes, sets the object state as 'use', creates a receiving cache queue, points to the cache queue through a receiving address, puts a service inquiry calling frame into a sending cache queue and enters a waiting state;
step 200, a client sends a cache queue to wait for receiving and sending tasks, and when data is put in, the data is sent;
step 300, the server receives the information waiting for inquiry or calling when the cache queue is suspended, if the received information is an inquiry message, whether the service exists in the server is inquired through the service ID and a mapping table of the service, if the service does not exist, the message is discarded, if the service exists, the corresponding function processing is called according to the service ID, then the result is packaged to a calling return frame, and the calling return frame is placed in a sending cache queue for sending;
step 400, after receiving the call frame, the client locates the CAN _ OBJ object according to the position ID in the query return frame, sends a message to a receiving cache queue according to a receiving address in the CAN _ OBJ object, and wakes up the call thread;
and 500, releasing the CAN _ OBJ object, putting the CAN _ OBJ object back to the tail part of the idle linked list, and deleting the receiving buffer queue.
Further, the data structure described is as follows:
the CAN _ OBJ object comprises a receiving end identifier, a transmitting end identifier, a client process mark, a frame type mark bit, a service ID, a data packet length, a data packet data content, a state, a receiving address and a next CAN _ OBJ object attribute;
the receiving end identifier and the transmitting end identifier are CAN bus unique identifiers and represent CAN bus address information;
the frame type flag bit is used for distinguishing whether the data frame is a query calling frame or a call returning frame;
hash table of service ID and specific service: inquiring and acquiring the service of the server through the service ID;
the status indicates whether the CAN _ OBJ object is idle or in use;
CAN _ OBJ object array: the array subscript is the ID of each CAN _ OBJ object, namely position ID, the Chinese name is client process mark, and the CAN _ OBJ object CAN be quickly positioned through the position ID;
idle CAN _ OBJ object linked list: connecting CAN _ OBJ objects in series in a linked list mode, enabling a head pointer to point to a first idle CAN _ OBJ object and a tail pointer to point to the tail of the idle CAN _ OBJ object, moving the head pointer backwards when a client applies for the idle CAN _ OBJ object, and moving the tail pointer backwards when the client releases the CAN _ OBJ object;
the client sends a buffer queue: storing a data frame to be transmitted from a client;
the client receives the buffer queue: storing an inquiry return result and a calling return result of a specific remote service calling request, wherein the receiveID in the CAN _ OBJ object points to a receiving cache queue, and after receiving information, the client analyzes the information and sends the information to the receiving cache queue according to the receiveID in the CAN _ OBJ object;
the server side sends a buffer queue: storing a data frame to be sent from a server;
the server side receives the buffer queue: deposit service queries and service invocation requests.
Still further, in step 100, the query call frame is designed as follows:
the CAN bus protocol data frame is divided into a CAN bus standard data frame and a CAN bus extension data frame, and the CAN bus standard data frame and the CAN bus extension data frame are mainly distinguished in that the CAN bus extension data frame comprises an 18-bit extension identifier; in order to better represent service requests and improve the data volume of a single protocol, the CAN bus expansion data frame is selected;
recording the originating address, client process mark, frame type mark bit, data packet length and service ID in the identifier of the query call frame, and recording the data content of the data packet in the data field of the query call frame.
Further, in step 300, the call return frame is designed as follows:
recording the originating address, the terminating address, the client process mark, the frame type mark bit and the data packet length in the identifier of the call return frame, and recording the return result in the data field of the call return frame.
The invention has the following beneficial effects: communication transmission capability is improved, and service with low time delay requirement is effectively supported.
Detailed Description
The invention is further described below.
A method for realizing service under the CAN bus environment comprises the following steps:
step 100, a client applies for a CAN _ OBJ object from an idle linked list, sets object attributes, sets the object state as 'use', creates a receiving cache queue, points to the cache queue through a receiving address, puts a service inquiry calling frame into a sending cache queue and enters a waiting state;
step 200, a client sends a cache queue to wait for receiving and sending tasks, and when data is put in, the data is sent;
step 300, the server receives the information waiting for inquiry or calling when the cache queue is suspended, if the received information is an inquiry message, whether the service exists in the server is inquired through the service ID and a mapping table of the service, if the service does not exist, the message is discarded, if the service exists, the corresponding function processing is called according to the service ID, then the result is packaged to a calling return frame, and the calling return frame is placed in a sending cache queue for sending;
step 400, after receiving the call frame, the client locates the CAN _ OBJ object according to the position ID in the query return frame, sends a message to a receiving cache queue according to a receiving address in the CAN _ OBJ object, and wakes up the call thread;
and 500, releasing the CAN _ OBJ object, putting the CAN _ OBJ object back to the tail part of the idle linked list, and deleting the receiving buffer queue.
Further, in step 100-500, the data structure is described as follows:
the CAN _ OBJ object comprises a receiving end identifier, a transmitting end identifier, a client process mark, a frame type mark bit, a service ID, a data packet length, a data packet data content, a state, a receiving address and a next CAN _ OBJ object attribute;
the receiving end identifier and the transmitting end identifier are CAN bus unique identifiers and represent CAN bus address information;
the frame type flag bit is used for distinguishing whether the data frame is a query calling frame or a call returning frame;
hash table of service ID and specific service: inquiring and acquiring the service of the server through the service ID;
the status indicates whether the CAN _ OBJ object is idle or in use;
CAN _ OBJ object array: the array subscript is the ID of each CAN _ OBJ object, namely position ID, the Chinese name is client process mark, and the CAN _ OBJ object CAN be quickly positioned through the position ID;
idle CAN _ OBJ object linked list: connecting CAN _ OBJ objects in series in a linked list mode, enabling a head pointer to point to a first idle CAN _ OBJ object and a tail pointer to point to the tail of the idle CAN _ OBJ object, moving the head pointer backwards when a client applies for the idle CAN _ OBJ object, and moving the tail pointer backwards when the client releases the CAN _ OBJ object;
the client sends a buffer queue: storing a data frame to be transmitted from a client;
the client receives the buffer queue: storing an inquiry return result and a calling return result of a specific remote service calling request, wherein the receiveID in the CAN _ OBJ object points to a receiving cache queue, and after receiving information, the client analyzes the information and sends the information to the receiving cache queue according to the receiveID in the CAN _ OBJ object;
the server side sends a buffer queue: storing a data frame to be sent from a server;
the server side receives the buffer queue: deposit service queries and service invocation requests.
Still further, in step 100, the query call frame is designed as follows:
the CAN bus protocol data frame is divided into a CAN bus standard data frame and a CAN bus extension data frame, and the CAN bus standard data frame and the CAN bus extension data frame are mainly distinguished in that the CAN bus extension data frame comprises an 18-bit extension identifier; in order to better represent service requests and improve the data volume of a single protocol, the CAN bus expansion data frame is selected;
recording the originating address, client process mark, frame type mark bit, data packet length and service ID in the identifier of the query call frame, and recording the data content of the data packet in the data field of the query call frame.
Further, in step 300, the call return frame is designed as follows:
recording the originating address, the terminating address, the client process mark, the frame type mark bit and the data packet length in the identifier of the call return frame, and recording the return result in the data field of the call return frame.
The embodiment realizes an RPC mechanism based on the CAN bus, changes the original form of explicitly sending and receiving messages between nodes, so that a user does not need to know a network interface and a use mode, and the function transparent calling is realized.
Different from a common RPC protocol based on a TCP/IP protocol stack, considering that the information data volume of a control system is small and the length of data allowed to be carried by each frame of a CAN bus is at most 8 bytes, the data length of a single-frame CAN is difficult to meet the call of complex services, so that the single-frame CAN is used for realizing the intelligent automobile service, and the requirements of some limitations exist: 1. in the self-defined service request calling protocol, only basic data types are allowed to be used, and complex types such as objects are not allowed to be used; 2. in the aspect of parameter group editing, actual parameters are only edited into a data field of the CAN data packet according to the sequence of parameters in a called function without a parameter type mark, parameters are extracted by a server side according to the sequence of the parameters in the function, and then the extracted parameters are brought into a corresponding function for operation; 3. the in-vehicle module has limited computing resources, and the service end generally cannot support the service provided for a plurality of clients at the same time, so that the service end only has one service providing process in the design for ensuring the normal operation of the service end.
Taking the implementation of coordinate conversion service as an example, a client applies for a CAN _ OBJ object from an idle linked list, sets object attributes, sets the object state to 'use', creates a receiving cache queue, points to the cache queue through a receiving address so as to send the result to the cache queue through the receiving address after returning the result from a server, creates an inquiry call frame, records a sending end address, a client process flag, a frame type flag bit, a data packet length and a service ID in an inquiry call frame identifier, records data packet data content in a data domain of the inquiry call frame, puts the service inquiry call frame into the sending cache queue, and enters a waiting state; the client sends a cache queue to wait for receiving a sending task, and sends data after the data is placed;
the server side receives the information waiting for inquiry or calling when the cache queue is hung, inquires the service through the service ID and the service mapping table if the received information is an inquiry message, inquires that the service exists, calls a corresponding coordinate conversion service function according to the coordinate conversion service ID, generates a return result, creates a calling return frame, records a transmitting end address, a receiving end address, a client process mark, a frame type mark bit and a data packet length in an identifier, and records the return result in a data domain of the calling return frame. Then packing the result to a call return frame, and placing the call return frame in a sending cache queue for sending;
after receiving the call frame, the client locates the CAN _ OBJ object according to the position ID in the query return frame, sends a message to a receiving cache queue according to a receiving address in the CAN _ OBJ object, and wakes up the call thread; and releasing the CAN _ OBJ object, putting back the tail part of the idle linked list, and deleting the receiving buffer queue.
The embodiments described in this specification are merely illustrative of implementations of the inventive concepts, which are intended for purposes of illustration only. The scope of the present invention should not be construed as being limited to the particular forms set forth in the examples, but rather as being defined by the claims and the equivalents thereof which can occur to those skilled in the art upon consideration of the present inventive concept.
Claims (4)
1. A method for realizing service under the CAN bus environment is characterized by comprising the following steps:
step 100, a client applies for a CAN _ OBJ object from an idle linked list, sets object attributes, sets the object state as 'use', creates a receiving cache queue, points to the cache queue through a receiving address, puts a service inquiry calling frame into a sending cache queue and enters a waiting state;
step 200, a client sends a cache queue to wait for receiving and sending tasks, and when data is put in, the data is sent;
step 300, the server receives the information waiting for inquiry or calling when the cache queue is suspended, if the received information is an inquiry message, whether the service exists in the server is inquired through the service ID and a mapping table of the service, if the service does not exist, the message is discarded, if the service exists, the corresponding function processing is called according to the service ID, then the result is packaged to a calling return frame, and the calling return frame is placed in a sending cache queue for sending;
step 400, after receiving the call frame, the client locates the CAN _ OBJ object according to the position ID in the query return frame, sends a message to a receiving cache queue according to a receiving address in the CAN _ OBJ object, and wakes up the call thread;
and 500, releasing the CAN _ OBJ object, putting the CAN _ OBJ object back to the tail part of the idle linked list, and deleting the receiving buffer queue.
2. The method of claim 1, wherein the data structure is described as follows:
the CAN _ OBJ object comprises a receiving end identifier, a transmitting end identifier, a client process mark, a frame type mark bit, a service ID, a data packet length, a data packet data content, a state, a receiving address and a next CAN _ OBJ object attribute;
the receiving end identifier and the transmitting end identifier are CAN bus unique identifiers and represent CAN bus address information;
the frame type flag bit is used for distinguishing whether the data frame is a query calling frame or a call returning frame;
hash table of service ID and specific service: inquiring and acquiring the service of the server through the service ID;
the status indicates whether the CAN _ OBJ object is idle or in use;
CAN _ OBJ object array: the array subscript is the ID of each CAN _ OBJ object, namely position ID, the Chinese name is client process mark, and the CAN _ OBJ object CAN be quickly positioned through the position ID;
idle CAN _ OBJ object linked list: connecting CAN _ OBJ objects in series in a linked list mode, enabling a head pointer to point to a first idle CAN _ OBJ object and a tail pointer to point to the tail of the idle CAN _ OBJ object, moving the head pointer backwards when a client applies for the idle CAN _ OBJ object, and moving the tail pointer backwards when the client releases the CAN _ OBJ object;
the client sends a buffer queue: storing a data frame to be transmitted from a client;
the client receives the buffer queue: storing an inquiry return result and a calling return result of a specific remote service calling request, wherein the receiveID in the CAN _ OBJ object points to a receiving cache queue, and after receiving information, the client analyzes the information and sends the information to the receiving cache queue according to the receiveID in the CAN _ OBJ object;
the server side sends a buffer queue: storing a data frame to be sent from a server;
the server side receives the buffer queue: deposit service queries and service invocation requests.
3. The method according to claim 1 or 2, wherein in step 100, the query call frame is designed as follows:
the CAN bus protocol data frame is divided into a CAN bus standard data frame and a CAN bus extension data frame, and the CAN bus standard data frame and the CAN bus extension data frame are mainly distinguished in that the CAN bus extension data frame comprises an 18-bit extension identifier; in order to better represent service requests and improve the data volume of a single protocol, the CAN bus expansion data frame is selected;
recording the originating address, client process mark, frame type mark bit, data packet length and service ID in the identifier of the query call frame, and recording the data content of the data packet in the data field of the query call frame.
4. The method according to claim 1 or 2, wherein the call return frame in step 300 is designed as follows:
recording the originating address, the terminating address, the client process mark, the frame type mark bit and the data packet length in the identifier of the call return frame, and recording the return result in the data field of the call return frame.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011187919.8A CN112532583A (en) | 2020-10-30 | 2020-10-30 | Method for realizing service under CAN bus environment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011187919.8A CN112532583A (en) | 2020-10-30 | 2020-10-30 | Method for realizing service under CAN bus environment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112532583A true CN112532583A (en) | 2021-03-19 |
Family
ID=74979266
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011187919.8A Pending CN112532583A (en) | 2020-10-30 | 2020-10-30 | Method for realizing service under CAN bus environment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112532583A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020116537A1 (en) * | 2000-12-28 | 2002-08-22 | Thomas Fuehrer | Method and communication system for data exchange among multiple users interconnected over a bus system |
| CN103684944A (en) * | 2012-09-10 | 2014-03-26 | 西门子信号有限公司 | Embedded gateway, railway monitoring system adopting gateway, and railway monitoring method |
| US20160112215A1 (en) * | 2014-10-17 | 2016-04-21 | Hyundai Motor Company | Method and apparatus for reducing load in can communication |
| CN108092864A (en) * | 2017-11-10 | 2018-05-29 | 北京全路通信信号研究设计院集团有限公司 | LEU equipment processing board and its communication processing apparatus and method |
| US20180159699A1 (en) * | 2016-12-05 | 2018-06-07 | Electronics And Telecommunications Research Institute | Can controller and data transmission method using the same |
| US20180278436A1 (en) * | 2015-09-03 | 2018-09-27 | Robert Bosch Gmbh | Method, device, and computer program for operating a data processing system |
-
2020
- 2020-10-30 CN CN202011187919.8A patent/CN112532583A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020116537A1 (en) * | 2000-12-28 | 2002-08-22 | Thomas Fuehrer | Method and communication system for data exchange among multiple users interconnected over a bus system |
| CN103684944A (en) * | 2012-09-10 | 2014-03-26 | 西门子信号有限公司 | Embedded gateway, railway monitoring system adopting gateway, and railway monitoring method |
| US20160112215A1 (en) * | 2014-10-17 | 2016-04-21 | Hyundai Motor Company | Method and apparatus for reducing load in can communication |
| US20180278436A1 (en) * | 2015-09-03 | 2018-09-27 | Robert Bosch Gmbh | Method, device, and computer program for operating a data processing system |
| US20180159699A1 (en) * | 2016-12-05 | 2018-06-07 | Electronics And Telecommunications Research Institute | Can controller and data transmission method using the same |
| CN108092864A (en) * | 2017-11-10 | 2018-05-29 | 北京全路通信信号研究设计院集团有限公司 | LEU equipment processing board and its communication processing apparatus and method |
Non-Patent Citations (5)
| Title |
|---|
| JIANQUN WANG; JINGXUAN CHEN; NING CAO: "A method to improve the stability and real-time ability of CAN", 《IEEE》 * |
| XIAN GAO; LIN-SHENG LI: "Analysis and Research of Real Time Ability of Message Transmission in CAN Bus", 《IEEE》 * |
| 吴敏: "《电动汽车整车控制器基础软件开发及控制策略研究》", 《中国优秀博硕士学位论文全文数据库(硕士)信息科技辑》 * |
| 施亚男: "《基于CAN总线的纯电动汽车监控软件设计》", 《中国优秀硕士学位论文全文数据库 工程科技Ⅱ辑》 * |
| 杨芳沛: "《视觉引导AGV车载运动控制系统开发》", 《中国优秀硕士学位论文全文数据库 (信息科技辑)》 * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106603394B (en) | Method and device for realizing subscription notification | |
| CN106612301B (en) | The method for pushing and device of more new data | |
| CN101668031B (en) | Message processing method and message processing system | |
| CN109756559B (en) | Construction and use method for distributed data distribution service of embedded airborne system | |
| CN110177118A (en) | A kind of RPC communication method based on RDMA | |
| CN112788074B (en) | Data transmitting method, processing method, receiving method, apparatus thereof, and storage medium | |
| CN104468704B (en) | Support the Web server system and processing method of content center network | |
| CN109996196A (en) | Route addressing method, short message downlink processing method, apparatus and system | |
| CN105635083A (en) | Service processing method and service processing system based on server and client architecture | |
| CN113010333A (en) | Multi-scene inter-process communication method suitable for Linux server cluster | |
| CN112565220A (en) | HTTP service gateway implementation method based on state network isolation device safety | |
| CN113329042B (en) | Message processing method and system, internet of vehicles system, server and electronic equipment | |
| CN112532583A (en) | Method for realizing service under CAN bus environment | |
| CN115865886B (en) | HTTP-based cross-network data interaction method and device | |
| CN1972276A (en) | A management method and system for protocol access | |
| CN109309711B (en) | Virtual cache sharing method and system | |
| CN110460526B (en) | Communication method for content-oriented networking data acquisition and distribution of Internet of things | |
| RU2003132458A (en) | METHOD FOR PERFORMING A SHORT MESSAGE TRANSFER SERVICE IN A MOBILE INTELLECTUAL NETWORK | |
| CN113973105B (en) | System and method for simplifying SOAP message on service bus | |
| CN108093084B (en) | Dynamic position information local updating and inquiring method for mobile network entity | |
| CN114143295B (en) | Transmission switch, FC-AE device and Ethernet device communication method | |
| CN114928660A (en) | Method for transparent interprocess communication of embedded operating system | |
| CN108848031A (en) | Information transferring method and device | |
| CN113727138A (en) | HLS intranet source returning method | |
| CN111130968A (en) | Method and terminal for solving Modbus bus communication packet sticking |
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 | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20210319 |
|
| RJ01 | Rejection of invention patent application after publication |