Search Results

Standard

High-Speed CAN (HSC) for Vehicle Applications at 250 kbps

2023-05-10

CURRENT

J2284/2_202305

This SAE Recommended Practice will define the Physical Layer and portions of the Data Link Layer of the Open Systems Interconnection model (ISO 7498) for a 250 kbps High Speed CAN (HSC) protocol implementation. Both ECU and media design requirements for networks will be specified. Requirements will primarily address the CAN physical layer implementation. Requirements will focus on a minimum standard level of performance from the High Speed CAN (HSC) implementation. All ECUs and media shall be designed to meet certain component level requirements in order to ensure the HSC implementation system level performance at 250 kbps. The minimum performance level shall be specified by system level performance requirements or characteristics described in detail in Section 5 of this document. This document is designed such that if the Electronic Control Unit (ECU) requirements defined in Section 6 are met, then the system level attributes should be obtainable.

Standard

Class A Multiplexing Actuators

2022-12-20

CURRENT

J2057/2_202212

The Class A Task Force of the Vehicle Network for Multiplex and Data Communications Committee is publishing this SAE Information Report to provide insight into Class A Multiplexing. Multiplexed actuators are generally defined as devices which accept information from the multiplexed bus. A multiplexed actuator can be an output device controlled by the operator or an intelligent controller. A Multiplex actuator can also be a display device that reports the status of a monitored vehicle function. This document is intended to help the network system engineers and is meant to stimulate the design thought process. A list of multiplexed actuator examples is provided in Appendix A, Figure A1. Many other examples can be it identified.

Standard

Class A Multiplexing Sensors

2022-12-20

CURRENT

J2057/3_202212

The Class A Task Force of the Vehicle Network for Multiplexing and Data Communications Subcommittee is providing information on sensors that could be applicable for a Class A Bus application. Sensors are generally defined as any device that inputs information onto the bus. Sensors can be an input controlled by the operator or an input that provides the feedback or status of a monitored vehicle function. Although there is a list of sensors provided, this list is not all-inclusive. This SAE Information Report is intended to help the network system engineer and is meant to stimulate the design thought process.

Standard

High-Speed CAN (HSC) for Vehicle Applications at 500 kbps with CAN FD Data at 5 Mbps

2022-11-02

CURRENT

J2284/5_202211

This SAE Recommended Practice will define the physical layer and portions of the data link layer of the open systems interconnection model (ISO 7498) for a 500 kbps arbitration bus with CAN FD data at 5 Mbps high-speed CAN (HSC) protocol implementation. Both ECU and media design requirements for networks will be specified. Requirements will primarily address the CAN physical layer implementation. Requirements will focus on a minimum standard level of performance from the High-Speed CAN (HSC) implementation. All ECUs and media shall be designed to meet certain component level requirements in order to ensure the HSC implementation system level performance at 500 kbps arbitration bus with CAN FD Data at 5 Mbps. The minimum performance level shall be specified by system level performance requirements or characteristics described in detail in Section 6 of this document.

Standard

High-Speed CAN (HSC) for Vehicle Applications at 500 kbps with CAN FD Data at 2 Mbps

2022-11-02

CURRENT

J2284/4_202211

This SAE Recommended Practice will define the physical layer and portions of the data link layer of the open systems interconnection model (ISO 7498) for a 500 kbps arbitration bus with CAN FD data at 2 Mbps high-speed CAN (HSC) protocol implementation. Both ECU and media design requirements for networks will be specified. Requirements will primarily address the CAN physical layer implementation. Requirements will focus on a minimum standard level of performance from the HSC implementation. All ECUs and media shall be designed to meet certain component level requirements in order to ensure the HSC implementation system level performance at 500 kbps arbitration bus with CAN FD data at 2 Mbps. The minimum performance level shall be specified by system level performance requirements or characteristics described in detail in Section 6 of this document.

Standard

High-Speed CAN (HSC) for Vehicle Applications at 500 kbps

2022-10-07

CURRENT

J2284/3_202210

This SAE Recommended Practice will define the physical layer and portions of the data link layer of the open systems interconnection model (ISO 7498) for a 500 kbps high-speed CAN (HSC) protocol implementation. Both electronic control unit (ECU) and media design requirements for networks will be specified. Requirements will primarily address the controller area network (CAN) physical layer implementation. Requirements will focus on a minimum standard level of performance from the HSC implementation. All ECUs and media shall be designed to meet certain component level requirements in order to ensure the HSC implementation system level performance at 500 kbps. The minimum performance level shall be specified by system level performance requirements or characteristics described in detail in Section 5 of this document. This document is designed such that if the ECU requirements defined in Section 6 are met, then the system level attributes should be obtainable.

Standard

LIN Network for Vehicle Applications

2021-10-01

CURRENT

J2602-1_202110

This document covers the requirements for SAE implementations based on ISO 17987:2016. Requirements stated in this document will provide a minimum standard level of performance to which all compatible ECUs and media shall be designed. This will assure full serial data communication among all connected devices regardless of supplier. The goal of SAE J2602-1 is to improve the interoperability and interchangeability of LIN devices within a network by adding additional requirements that are not present in ISO 17987:2016 (e.g., fault tolerant operation, network topology, etc.). The intended audience includes, but is not limited to, ECU suppliers, LIN controller suppliers, LIN transceiver suppliers, component release engineers, and vehicle system engineers. The term “master” has been replaced by “commander” and term “slave” with “responder” in the following sections.

Standard

Communication Transceivers Qualification Requirements - Ethernet

2021-09-21

HISTORICAL

J2962-3_202109

This SAE Recommended Practice covers the requirements for ethernet physical layer (PHY) qualification. Requirements stated in this document provide a minimum standard level of performance for the PHY in the IC to which all compatible ethernet communications PHY shall be designed. When the communications chipset is an ethernet switch with an integrated automotive PHY (xBASE-T1), then the testing shall include performance for all switch PHY ports as well as each controller interface. No other features in the IC are tested or qualified as part of this SAE Recommended Practice. This assures robust serial data communication among all connected devices regardless of supplier. The goal of SAE J2962-3 is to commonize approval processes of ethernet PHYs across OEMs. The intended audience includes, but is not limited to, ethernet PHY suppliers, component release engineers, and vehicle system engineers.

Standard

Bluetooth™ Wireless Protocol for Automotive Applications

2016-11-08

CURRENT

J2561_201611

This SAE Information Report defines the functionality of typical Bluetooth applications used for remotely accessing in-vehicle automotive installations of electronic devices. Remote access may be achieved directly with on-board Bluetooth modules, or indirectly via a custom designed gateway that communicates with Bluetooth and non-Bluetooth modules alike. Access to the vehicle, in the form of two-way communications, may be made via a single master port, or via multiple ports on the vehicle. The Bluetooth technology may also be used in conjunction with other types of off-board wireless technology. This report recommends using a message strategy that is already defined in one or more of the documents listed in 2.1.1, 2.1.4, 2.1.5, and 2.1.6. Those strategies may be used for some of the typical remote communications with a vehicle. It is recognized, however, that there may be specific applications requiring a unique message strategy or structure.

Standard

LIN Network for Vehicle Applications

2012-11-19

HISTORICAL

J2602/1_201211

This document covers the requirements for SAE implementations based on LIN 2.0. Requirements stated in this document will provide a minimum standard level of performance to which all compatible ECUs and media shall be designed. This will assure full serial data communication among all connected devices regardless of supplier. The goal of SAE J2602-1 is to improve the interoperability and interchangeability of LIN devices within a network by resolving those LIN 2.0 requirements that are ambiguous, conflicting, or optional. Moreover, SAE J2602-1 provides additional requirements that are not present in LIN 2.0 (e.g., fault tolerant operation, network topology, etc.). This document is to be referenced by the particular vehicle OEM component technical specification that describes any given ECU in which the single wire data link controller and physical layer interface is located. Primarily, the performance of the physical layer is specified in this document.

Standard

LIN Network for Vehicle Applications Conformance Test

2012-11-19

HISTORICAL

J2602/2_201211

This document covers the tests to be performed on all SAE J2602-1 defined Master and Slave nodes. Tests described in this document will ensure a minimum standard level of performance to which all compatible Electronic Control Unit (ECUs) and media shall be designed. This will assure full serial data communication among all connected devices regardless of supplier. The goal of SAE J2602-2 is to improve the interoperability and interchangeability of LIN devices within a network by verifying the devices pass a minimum set of tests. To allow for easy cross-reference, this document is arranged such that the conformance test for a given section in SAE J2602-1 is in the same section in SAE J2602-2. This document is to be referenced by the particular vehicle Original Equipment Manufacturer (OEM) component technical specification that describes any given ECU in which the LIN data link controller and physical layer interface is located.

Standard

Class B Data Communication Network Messages - Part 3 - Frame IDs for Single-Byte Forms of Headers

2011-05-02

CURRENT

J2178/3_201105

This SAE Recommended Practice defines the information contained in the header and data fields of non-diagnostic messages for automotive serial communications based on SAE J1850 Class B networks. This document describes and specifies the header fields, data fields, field sizes, scaling, representations, and data positions used within messages. The general structure of a SAE J1850 message frame without in-frame response is shown in Figure 1. The structure of a SAE J1850 message with in-frame response is shown in Figure 2. Figures 1 and 2 also show the scope of frame fields defined by this document for non-diagnostic messages. Refer to SAE J1979 for specifications of emissions related diagnostic message header and data fields. Refer to SAE J2190 for the definition of other diagnostic data fields. The description of the network interface hardware, basic protocol definition, electrical specifications, and the CRC byte is given in SAE J1850.

Standard

Class B Data Communication Network Messages - Part 2: Data Parameter Definitions

2011-04-01

CURRENT

J2178/2_201104

This SAE Recommended Practice defines the information contained in the header and data fields of non-diagnostic messages for automotive serial communications based on SAE J1850 Class B networks. This document describes and specifies the header fields, data fields, field sizes, scaling, representations, and data positions used within messages. The general structure of a SAE J1850 message frame without in-frame response is shown in Figure 1. The structure of a SAE J1850 message with in-frame response is shown in Figure 2. Figures 1 and 2 also show the scope of frame fields defined by this document for non-diagnostic messages. Refer to SAE J1979 for specifications of emissions related diagnostic message header and data fields. Refer to SAE J2190 for the definition of other diagnostic data fields. The description of the network interface hardware, basic protocol definition, electrical specifications, and the CRC byte are given in SAE J1850.

Standard

Class B Data Communication Network Messages - Message Definitions for Three Byte Headers

2011-04-01

CURRENT

J2178/4_201104

This SAE Recommended Practice defines the information contained in the header and data fields of non-diagnostic messages for automotive serial communications based on SAE J1850 Class B networks. This document describes and specifies the header fields, data fields, field sizes, scaling, representations, and data positions used within messages. The general structure of a SAE J1850 message frame without in-frame response is shown in Figure 1. The structure of a SAE J1850 message with in-frame response is shown in Figure 2. Figures 1 and 2 also show the scope of frame fields defined by this document for non-diagnostic messages. Refer to SAE J1979 for specifications of emissions related diagnostic message header and data fields. Refer to SAE J2190 for the definition of other diagnostic data fields. The description of the network interface hardware, basic protocol definition, the electrical specifications, and the CRC byte are given in SAE J1850.

Standard

Class B Data Communication Network Messages - Detailed Header Formats and Physical Address Assignments

2011-04-01

CURRENT

J2178/1_201104

This SAE Recommended Practice defines the information contained in the header and data fields of non-diagnostic messages for automotive serial communications based on SAE J1850 Class B networks. This document describes and specifies the header fields, data fields, field sizes, scaling, representations, and data positions used within messages. The general structure of a SAE J1850 message frame without in-frame response is shown in Figure 1. The structure of a SAE J1850 message with in-frame response is shown in Figure 2. Figures 1 and 2 also show the scope of frame fields defined by this document for non-diagnostic messages. Refer to SAE J1979 for specifications of emissions related diagnostic message header and data fields. Refer to SAE J2190 for the definition of other diagnostic data fields. The description of the network interface hardware, basic protocol definition, the electrical specifications, and the CRC byte are given in SAE J1850.

Standard

File Structures for a Node Capability File (NCF)

2010-01-07

HISTORICAL

J2602/3_201001

This document covers the requirements for SAE implementations based on LIN 2.0. Requirements stated in this document will provide a minimum standard level of performance to which all compatible systems, design and development tools, software, ECUs and media shall be designed. This will assure consistent and unambiguous serial data communication among all connected devices regardless of supplier. This document may be referenced by any vehicle OEM component technical specification that describes any given ECU in which the single wire data link controller and physical layer interface is located. The intended audience includes, but is not limited to, ECU suppliers, LIN controller suppliers, LIN transceiver suppliers, component release engineers and vehicle system engineers.

Standard

Class A Multiplexing Actuators

2006-09-12

HISTORICAL

J2057/2_200609

The Class A Task Force of the Vehicle Network for Multiplex and Data Communications Committee is publishing this SAE Information Report to provide insight into Class A Multiplexing. Multiplexed actuators are generally defined as devices which accept information from the multiplexed bus. A multiplexed actuator can be an output device controlled by the operator or an intelligent controller. A Multiplex actuator can also be a display device that reports the status of a monitored vehicle function. This document is intended to help the network system engineers and is meant to stimulate the design thought process. A list of multiplexed actuator examples is provided in Appendix A, Figure A1. Many other examples can be it identified.

Standard

Class A Multiplexing Sensors

2006-09-12

HISTORICAL

J2057/3_200609

The Class A Task Force of the Vehicle Network for Multiplexing and Data Communications Subcommittee is providing information on sensors that could be applicable for a Class A Bus application. Sensors are generally defined as any device that inputs information onto the bus. Sensors can be an input controlled by the operator or an input that provides the feedback or status of a monitored vehicle function. Although there is a list of sensors provided, this list is not all-inclusive. This SAE Information Report is intended to help the network system engineer and is meant to stimulate the design thought process.

Standard

Class A Multiplexing Architecture Strategies

2006-09-12

HISTORICAL

J2057/4_200609

The subject matter contained within this SAE Information Report is set forth by the Class A Task Force of the Vehicle Network for Multiplexing and Data Communications (Multiplex) Committee as information the network system designer should consider. The Task Force realizes that the information contained in this report may be somewhat controversial and a consensus throughout the industry does not exist at this time. The Task Force also intends that the analysis set forth in this document is for sharing information and encouraging debate on the benefits of utilizing a multiple network architecture.

Standard

Class A Application/Definition

2006-09-12

HISTORICAL

J2057/1_200609

This SAE Information Report will explain the differences between Class A, B, and C networks and clarify through examples, the differences in applications. Special attention will be given to a listing of functions that could be attached to a Class A communications network.