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 Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2057-4 Reaffirmed SEP2006 - 2 - 6. Proposed Vehicle Architecture . 8 6.1 Engine Compartment Node 10 6.2 Doo
10、r 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 Conclusions. 13 8.1 Advantages and Disadvantages 13 Appendix A 14 1. SCOPE The subject matter contained within this SAE Information Report is set fort
11、h 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
12、 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. 1.1 Three Classes Multiplex Networks The Vehicle Network for Multiplexin
13、g and Data Communications (Multiplex) Committee has defined three classes of vehicle data communication networks. 1.1.1 Class A Low-Speed Body Wiring 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-
14、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 intended 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 functi
15、ons 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 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 Pu
16、blications The following publications form a part of the specification to the extent specified herein. Unless otherwise indicated, the latest revision of SAE publications shall apply. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permit
17、ted without license from IHS-,-,-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 Inter
18、face 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 n
19、ot 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 #8
20、9123, 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. 3
21、.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 d
22、ata 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 with
23、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 or
24、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 beco
25、me our base assumptions. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2057-4 Reaffirmed SEP2006 - 4 - 4.1 Multiple Network Architecture Background Initially, the Vehicle Network for Multiplex
26、ing and Data Communications Committee recognized the three different requirements for vehicle networking. A chart of these three vehicle multiplex 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 consens
27、us by the Multiplexing Committee. The chart shown in Figure 1 does not mean that three networks are needed to cover the multiplexing requirements, but that there are three different characteristic requirements within the vehicle that must be considered. Some of the entries in the chart such as “Stat
28、us” and “Data Consistency” were not totally understood as noted by the missing entry under Class A. For example the “Status” entry was eventually recognized as the need for acknowledgement in a Class A Network. Some entries had slightly different meanings between committee members and, therefore, fu
29、rther development was dropped. The purpose of this document is not to explain all the characteristic requirements of vehicle networking, but to focus 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 networ
30、k architecture strategy requires a careful study of the alternatives. This investigation of multiple network architectures begins with the assumption that a lower total vehicle system cost would result if one network were optimized around a data communications requirement and other networks were opt
31、imized around the sensor and control requirements. Consider first the ramifications of optimizing a network around the data communications requirements, i.e., Class B multiplexing. Class B multiplexing interconnects intelligent modules such as the engine controller, body computer, vehicle instrument
32、 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 may reduce the connections between sensors and modules. Class B Multiplexing in this case provides an intermodule data communications link for distribute
33、d processing. The parametric data shared between modules is almost exclusively repetitive in nature and rarely do these modules require handshaking or acknowledgement of data with other modules. Therefore, a network can be optimized around functional addressing. This is the result of handling the do
34、minance 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 multiplex application so optimized by handling the dominance of time-based data communications requirements (see SAE J1850). When physical addressing is re
35、quired in a data communication optimized network, usually for vehicle diagnostics, it can be handled without reducing efficiency. The amount of safety type data that a data communications optimized network has to handle is negligible and can be very effectively handled by other means such as discret
36、e hard wiring. Hard wiring of sensitive functions is considered an advantage because it is consistent with the present conservative method of handling these functions. When the encumbrance of handling safety type data and most Class A (sensor and control multiplexing) functions are eliminated from t
37、he network requirements, a significantly simpler data communications network is the result. This multiple network architectural philosophy also results in a simpler and more effective method of handling sensor and control multiplexing. The logistical size and complexity of the vehicle manufacturers
38、systems organization is another factor to be considered. The multiple network architecture is better suited to development and production by multiple sources: a situation that may be important to some vehicle manufacturers. The multiple network architecture requires only a moderate systems organizat
39、ion to insure compatibility because fewer messages would be supported by the data communication network. The sensor and control subsystem requirements can be handled by the product development organization with less direction from the system engineering group. This direction is possible because most
40、 of the subsystem would interface with their relevant sensors via their own dedicated Class A Network. The multiple network architecture strategy should not be a hindrance to multiplex standardization because the Class B Network would be used to support diagnostics. Copyright SAE International Provi
41、ded by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-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 softw
42、are 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 with S
43、AE 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 micro
44、computers 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 number
45、of optimized and simpler solutions can be developed to handle the many and differing requirements of the vehicle multiplex spectrum. Copyright SAE International Provided by IHS under license with SAENot for ResaleNo reproduction or networking permitted without license from IHS-,-,-SAE J2057-4 Reaffi
46、rmed SEP2006 - 6 - 4.2 Single Network Architecture Background The single network architecture strategy alternative that meets the requirements of 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
47、are repetitive in nature) and control-type messages (which are event-driven by nature), the control-type message dominates in hardware and software complexity. Control-type messages, such as turn headlights on, are easily understood as event-based. A more complex situation is where parametric data s
48、uch 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 speed 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 critic
49、al than a loss of a message in a time-based protocol where the data is naturally repetitive for the message being transmitted is generally current status. The addition of an acknowledgement to the protocol is a possible solution and the following complexity ramifications should be considered: a. RAM
