LIN Network for Vehicle Applications
- Ground Vehicle Standard
- J2602/1_200509
- Revised
Rationale
-
1
Section 3.1 – Added definitions for Command Frame and Request Frame.
-
2
Section 5.3 – It was decided that the Master device should detect errors and stop transmitting when an error is detected during the message header. This will simplify the Master software and will make the behavior of the bus more predictable.
-
3
Section 5.4.1 – The names of the errors in this section did not match the names of the errors in Sections 5.8.5.1.3-6 where they are described. They will now match.
-
4
Section 5.4.3 – The spec now explicitly states that if the sync byte data received by the slave is not correct the slave shall set an error code and ignore the rest of the message.
-
5
Section 5.5 - TFrame_Maximum was used twice for the range, the first time it should have been TFrame_Minimum.
-
6
Section 5.7.2.5 – The Broadcast message IDs mapping has been clarified.
-
7
Section 5.7.3 – Added additional requirements for device behavior when a Targeted Reset command is received to make the behavior more predictable.
-
8
Section 5.8.2 – Added a note about signal consistency in the J2602 Status Byte.
-
9
New Section 5.8.4 – Inserted between 5.8.3 and old 5.8.4. Define repeat usage of signals in frames.
-
10
Section 5.8.6.1.3 – Tx Bit Error has been changed to Data Error to include the case where a slave receives a data byte other than $55 for the sync byte.
-
11
Section 5.8.6.2.1 – This section has been added to define a use for APINFO4. This bit has now been defined to indicate that the Slave application is requesting service from the Master.
-
12
Section 6.3 – Refers to J2602-3 for API requirements.
-
13
Section 7.2.1 – The wake-up pulses sent by the slave had minimum times between repeats, but no maximum times. This has been addressed.
-
14
Section 7.12.2 – Additional information has been added as to the behavior of the system during an over-voltage event.
Data Sets - Support Documents
Issuing Committee
Vehicle Architecture For Data Communications Standards
The ever-increasing consumer expectations of vehicle internal functions and connectivity to the environment are outstripping the capability of current data communication architecture design. To address this vulnerability, this committee will investigate and endorse new vehicle architectures that meet system requirements such as: Reliability, System design metrics, Data security, Fault Tolerance, Built in testability, Validation/Verification , Compatibility, and Redundancy. This committee's mission is the investigation and development of vehicle architecture and data communication protocols and methods required to achieve the growth expected in the area of vehicle electronics. The committee shall continue to contribute to the understanding and use of semiconductor devices such as microprocessors, power devices, and other integrated circuits and the data transmission media used in these systems. Thus, all vehicle architectures (excluding aircraft) and devices used in these systems shall be included. Specific objectives shall include: Address the effect of electrical power environments (e.g., 42V, ground offsets) , Sponsor forums to evaluate new technologies (e.g., MOST, Bluetooth, Firewire), Publish technical reports on vehicle architecture and system partitioning, interfacing, modes of operation, protocol standards, recommended conformance test methods, and evaluation methods of those standards , Maintain the existing documents relevant to this committee (e.g., glossary of automotive electronics terms, SAE J1213/1), Encourage the applicable industries, government and educational institutions to support the efforts of this committee.