1、_ SAE Technical Standards Board Rules provide that: “This report is published by SAE to advance the state of technical and engineering sciences. The use of this report is entirely voluntary, and its applicability and suitability for any particular use, including any patent infringement arising there
2、from, is the sole responsibility of the user.” SAE reviews each technical report at least every five years at which time it may be reaffirmed, revised, or cancelled. SAE invites your written comments and suggestions. Copyright 2006 SAE International All rights reserved. No part of this publication m
3、ay be reproduced, stored in a retrieval system or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of SAE. TO PLACE A DOCUMENT ORDER: Tel: 877-606-7323 (inside USA and Canada) Tel: 724-776-4970 (outside USA)
4、 Fax: 724-776-0790 Email: CustomerServicesae.org SAE WEB ADDRESS: http:/www.sae.org J2057-4 REAF. SEP2006 SURFACE VEHICLE INFORMATION REPORT Issued 1993-06 Reaffirmed 2006-09 Superseding J2057-4 AUG2001 Class A Multiplexing Architecture Strategies RATIONALE This document has been reaffirmed to compl
5、y with the SAE 5-Year Review policy. FOREWORD There are generally three classes of multiplex application requirements within the vehicle. To cover these applications two prevalent multiplex architecture strategies have developed. The most popular is the Single Network Architecture. This architectura
6、l strategy sizes the network hardware to meet the requirements of the highest level application while maintaining the capability, where possible, of handling the lowest level application. The second strategy, Multiple Network Architecture, is to develop as many types of specialized network hardware
7、components as required to efficiently handle each application and then gateway them together to have only one diagnostic service port. These two differing strategies are studied in detail and presented in this SAE Information Report. TABLE OF CONTENTS 1. Scope 2 1.1 Three Classes Multiplex Networks
8、. 2 2. References 2 2.1 Applicable Publication. 2 2.2 Related Publications . 3 3. Definitions . 3 4. Multilex Wiring System Architecture Strategies 3 4.1 Multiple Network Architecture Background. 4 4.2 Single Network Architecture Background . 6 5. Role of Class A Multiplexing . 6 5.1 Other Driving F
9、orces. 7 5.2 Example Class A Systems 7 SAE J2057-4 Reaffirmed SEP2006 - 2 - 6. Proposed Vehicle Architecture . 8 6.1 Engine Compartment Node 10 6.2 Door Nodes. 10 6.3 General Node Concerns . 10 6.4 Multiple Network Architecture . 11 7. Requirements for Class A Sensors and Actuators 12 8. Summary and
10、 Conclusions. 13 8.1 Advantages and Disadvantages 13 Appendix A 14 1. SCOPE 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 d
11、esigner 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 en
12、couraging debate on the benefits of utilizing a multiple network architecture. 1.1 Three Classes Multiplex Networks The Vehicle Network for Multiplexing and Data Communications (Multiplex) Committee has defined three classes of vehicle data communication networks. 1.1.1 Class A Low-Speed Body Wiring
13、 and Control Functions, e.g., Control of Exterior Lamps 1.1.2 Class B Data Communications, i.e., Sharing of Vehicle Parametric Data 1.1.3 Class C High-Speed Real Time Control, e.g., High-Speed Link for Distributed Processing 1.1.4 Interrealtionship of Classes A, B, and C The Class B Network is inten
14、ded to be a functional superset of the Class A Network. That is, the Class B Bus must be capable of communications that would perform all of the functions of a Class A Bus. This feature protects the use of the same bus for all Class A and Class B functions or an alternate configuration of both buses
15、 with a “gateway” device. In a similar manner, the Class C Bus is intended as a functional superset of the Class B Bus. 2. REFERENCES 2.1 Applicable Publications The following publications form a part of the specification to the extent specified herein. Unless otherwise indicated, the latest revisio
16、n of SAE publications shall apply. SAE J2057-4 Reaffirmed SEP2006 - 3 - 2.1.1 SAE Publications Available from SAE, 400 Commonwealth Drive, Warrendale, PA 15096-0001, Tel: 877-606-7323 (inside USA and Canada) or 724-776-4970 (outside USA), www.sae.org. SAE J1850 Class B Data Communication Network Int
17、erface SAE J2057-1 Class A Application/Definition SAE J2058 Chrysler Sensor and Control (CSC) Bus Multiplexing for Class A Applications SAE J2178-1-2-3-4 Class B Data Communication Network Messages 2.2 Related Publications The following publications are provided for information purposes only and are
18、 not a required part of this document. Thomas R. Wrobleski, “A Multiplexed Automotive Sensor System,” Sensors Magazine dated February 1989, Volume 6, No. 2 Thomas R. Wrobleski, “A CSC Bus Multiplexing Technique for Sensors and Actuators Which Allows Common Vehicle Electronic Control Modules,” Paper
19、#89123, 20th International Symposium on Automotive Technology and Automation, Florence, Italy, May 1989 3. DEFINITIONS 3.1 Event-based The attribute of transmission of data on a manually triggered event or on change of parametric value. 3.2 Event-driven The attribute of event-based network protocol.
20、 3.3 Response-Type Messages Messages that require Acknowledgement. 3.4 T-tap A splice in a wiring harness forming a “T” connection. Sometimes this configuration is associated with automated insulation displacement type connection at a connector. 3.5 Time-based The attributes of repetitive parametric
21、 data in a Class B Multiplex Network. 4. MULTIPLEX WIRING SYSTEM ARCHITECTURE STRATEGIES It is a well-known fact that the cost of electronics is decreasing. More functions can now be integrated into fewer modules. The availability of Class B multiplexing now avails the automotive system designer wit
22、h many new architecture partitioning options. The availability of customer-specific ICs to accomplish a function at a substantially lower cost is becoming a reality. On the other side of the equation is rising wiring and labor costs. Vehicle manufacturers have, in some instances, gone to off-shore o
23、r other countries to offset these labor-intensive assembly costs. However, the growth in size and complexity of wiring harnesses causes an ever-increasing investment in assembly facilities that overshadows these cost-containment efforts. These basic trends are projected to apply in the future and be
24、come our base assumptions. SAE J2057-4 Reaffirmed SEP2006 - 4 - 4.1 Multiple Network Architecture Background Initially, the Vehicle Network for Multiplexing and Data Communications Committee recognized the three different requirements for vehicle networking. A chart of these three vehicle multiplex
25、networking typical characteristics is shown in Figure 1. This chart was presented late in 1986 to the SAE Truck and Bus Committee as the state of consensus by the Multiplexing Committee. The chart shown in Figure 1 does not mean that three networks are needed to cover the multiplexing requirements,
26、but that there are three different characteristic requirements within the vehicle that must be considered. Some of the entries in the chart such as “Status” and “Data Consistency” were not totally understood as noted by the missing entry under Class A. For example the “Status” entry was eventually r
27、ecognized as the need for acknowledgement in a Class A Network. Some entries had slightly different meanings between committee members and, therefore, further development was dropped. The purpose of this document is not to explain all the characteristic requirements of vehicle networking, but to foc
28、us on the Class A and Class B interrelationship and, therefore, there will be no further discussion on Figure 1. The decision to pursue a multiple network architecture strategy requires a careful study of the alternatives. This investigation of multiple network architectures begins with the assumpti
29、on that a lower total vehicle system cost would result if one network were optimized around a data communications requirement and other networks were optimized around the sensor and control requirements. Consider first the ramifications of optimizing a network around the data communications requirem
30、ents, i.e., Class B multiplexing. Class B multiplexing interconnects intelligent modules such as the engine controller, body computer, vehicle instrument cluster, and other electronic modules. It normally does not affect the base vehicle wiring such as lighting, but it does affect wiring in that it
31、may reduce the connections between sensors and modules. Class B Multiplexing in this case provides an intermodule data communications link for distributed processing. The parametric data shared between modules is almost exclusively repetitive in nature and rarely do these modules require handshaking
32、 or acknowledgement of data with other modules. Therefore, a network can be optimized around functional addressing. This is the result of handling the dominance of repetitive data and only a small amount of response type data, e.g., diagnostic data. It is consistent with this strategy to define a mu
33、ltiplex application so optimized by handling the dominance of time-based data communications requirements (see SAE J1850). When physical addressing is required in a data communication optimized network, usually for vehicle diagnostics, it can be handled without reducing efficiency. The amount of saf
34、ety type data that a data communications optimized network has to handle is negligible and can be very effectively handled by other means such as discrete hard wiring. Hard wiring of sensitive functions is considered an advantage because it is consistent with the present conservative method of handl
35、ing these functions. When the encumbrance of handling safety type data and most Class A (sensor and control multiplexing) functions are eliminated from the network requirements, a significantly simpler data communications network is the result. This multiple network architectural philosophy also res
36、ults in a simpler and more effective method of handling sensor and control multiplexing. The logistical size and complexity of the vehicle manufacturers systems organization is another factor to be considered. The multiple network architecture is better suited to development and production by multip
37、le sources: a situation that may be important to some vehicle manufacturers. The multiple network architecture requires only a moderate systems organization to insure compatibility because fewer messages would be supported by the data communication network. The sensor and control subsystem requireme
38、nts can be handled by the product development organization with less direction from the system engineering group. This direction is possible because most of the subsystem would interface with their relevant sensors via their own dedicated Class A Network. The multiple network architecture strategy s
39、hould not be a hindrance to multiplex standardization because the Class B Network would be used to support diagnostics. SAE J2057-4 Reaffirmed SEP2006 - 5 - FIGURE 1 - CHART OF TYPICAL VEHICLE MULTIPLEXING CHARACTERISTICS This multiplexing strategy does have many other advantages. For example, the s
40、oftware required for system control is simplified because it is not required to support timers, counters, or other response types of communications or control. The interfacing hardware is simplified and a less-complex microcomputer is normally required. The data communication rates are consistent wi
41、th SAE J1850 single wire interfacing, which also supports a lower-cost solution. Data communication multiplexing requirements are consistent, and tend to be associated with the cost-proven technique of integration of body feature modules. As system designers choose between 4-bit, 8-bit, and 16-bit m
42、icrocomputers and apply them to their requirements, one would similarly think that Class A is most likely to be bit oriented, Class B is likely to be byte oriented and Class C is likely to be message oriented. The multiple network architectural philosophy also conforms with the reasoning where a num
43、ber of optimized and simpler solutions can be developed to handle the many and differing requirements of the vehicle multiplex spectrum. SAE J2057-4 Reaffirmed SEP2006 - 6 - 4.2 Single Network Architecture Background The single network architecture strategy alternative that meets the requirements of
44、 both Class A and B classifications leads to a more complex and costly solution. In order to handle data communications or time-based type messages (which are repetitive in nature) and control-type messages (which are event-driven by nature), the control-type message dominates in hardware and softwa
45、re complexity. Control-type messages, such as turn headlights on, are easily understood as event-based. A more complex situation is where parametric data such as vehicle speed, which is defined to be time-based type messages must transmit only on change in parametric value, e.g., change in vehicle s
46、peed from 45 to 46 mph to represent an event for transmission as an event-based message. In this event-based protocol a loss of message is much more critical than a loss of a message in a time-based protocol where the data is naturally repetitive for the message being transmitted is generally curren
47、t status. The addition of an acknowledgement to the protocol is a possible solution and the following complexity ramifications should be considered: a. RAM is required to save message(s) and control data for messages. b. Messages may need to be saved while they await acknowledgement. c. Timer data a
48、ssociated with a given message may need to be maintained while messages wait for acknowledgement. d. A retry counter data associated with a given message may need to be maintained while messages await acknowledgement. In a time-based protocol, acknowledgement of data may add unnecessary complexity.
49、This condition can be easily understood by considering the situation where a given copy of a message is not received, for whatever reason, and another more current copy will be coming shortly. There is no reason to keep a copy of the current message so that it can be retransmitted if the previous transmission is not acknowledged. Generally, there is nothing that a module can do if one of its messages is not acknowledged aside from the excepti
