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 entirelyvoluntary, and its applicability and suitability for any particular use, including any patent infringement arising therefro
2、m, 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.TO PLACE A DOCUMENT ORDER: (724) 776-4970 FAX: (724) 776-0790SAE WEB ADDRESS http:/www.s
3、ae.orgCopyright 2002 Society of Automotive Engineers, Inc.All rights reserved. Printed in U.S.A.SURFACEVEHICLE400 Commonwealth Drive, Warrendale, PA 15096-0001STANDARDJ2546 ISSUEDFEB2002Issued 2002-02Model Specification Process StandardTABLE OF CONTENTS1. Scope . 21.1 Background 21.2 Purpose 21.3 Mo
4、del Development 21.4 Application 52. References . 62.1 Related Publications. 63. Definitions. 64. EE Commodity Analysis and Modeling Considerations 104.1 Analysis Requirements. 104.1.1 Types of Analysis. 114.1.2 Analysis Methodology and Simulation Tools 114.2 Modeling Considerations 124.2.1 Modeling
5、 of Wholly Electrical Commodities 124.2.2 Modeling of Mechatronic Commodities . 124.2.3 Modeling Non-Electrical Entities in the Control Loop . 124.2.4 Modeling of Control Modules 134.2.5 Control System Modeling . 135. Modeling Fidelity . 135.1 Levels of Model Refinement . 135.2 Levels of Feature Con
6、tent 155.3 Forms of Simulation Results. 165.4 Diminishing Returns of Fidelity. 165.5 Accommodating Different Fidelity Needs in a Model 166. Modeling Assumptions: 166.1 Units of Measurements. 166.2 Connection Type Definition. 166.2.1 Standard Sign Convention 176.3 Reference . 17SAE J2546 Issued FEB20
7、02-2-6.4 Model Assumptions 176.5 Environmental and Operating Conditions .176.6 Input Parameters 176.7 Supplementary Output Variables 187. Model Architecture187.1 External Signal Interface Requirements .187.2 Model Internal Requirements187.3 Textual Messages .197.3.1 Informational Messages197.3.2 Ove
8、rstress Messages .197.3.3 Warning Messages .197.3.4 Error Messages 198. Validation Requirements.198.1 Functional Test Procedures 198.2 Characterization Test Procedures.198.3 Data Reduction Procedure .198.4 Validation Procedure and Data .208.5 Validation Criteria209. Deliverables 209.1 Models 209.1.1
9、 Source Code.209.1.1.1 Header 209.1.1.2 Comments 209.1.1.3 Programming Languages209.1.1.4 Drawing Symbols 209.1.2 Supporting Deliverables219.2 Documentation219.2.1 Model Application Documentation 219.2.1.1 Description219.2.1.2 Netlist or Dataflow Hierarchy 219.2.1.3 Input Parameters 219.2.1.4 Connec
10、tion Points.219.2.1.5 Output Variables .219.2.1.6 Usage Notes .219.2.2 Support Documentation219.2.2.1 Model Features .219.2.2.1.1 Connection Points.219.2.2.1.2 Parameters .219.2.2.2 Template Usage219.2.2.3 Model Limitations229.2.2.4 Model Theory229.2.2.5 Characterization Test Procedures and Data .22
11、9.2.2.5.1 Equipment Used .229.2.2.5.2 Data Acquisition Procedure 229.2.2.6 Model Validation Data.229.2.2.7 Model Datafile.229.2.2.8 Appendices .229.3 Support .22Appendix A EE Commodities .23Appendix B Example Saber Modelfile Header Layout .30SAE J2546 Issued FEB2002-3-1. ScopeThe modeling requiremen
12、ts listed in this document provide guidelines for specifying:Analysis requirementsComputer-Aided Engineering (CAE) simulator Model fidelity System assumptionsModel architectureValidation requirementsDeliverables for electrical/electronic components and the integral interfacing systems (mechanical, t
13、hermal, hydraulic)associated with these components.The simulation models are primarily intended to facilitate functional specification and operational evaluationbetween component and system manufacturers, and are not intended to otherwise constrain or restrict the useof CAE simulation tools for auto
14、motive design, analysis and validation.1.1 BackgroundThe advances in computer technology since the 1970s have enabled the development ofpowerful CAE tools. These tools are being increasingly applied to the highly competitive automotive industryfor the development of new components and systems. CAE t
15、ools allow companies to reduce the number ofprototype phases and are considered key enablers in their product development process to produce designs inless time, with higher quality and lower costs.However, over the years many custom tools have been developed with specific modeling and analysisobjec
16、tives. Today, suppliers are asked more and more to deliver component models that satisfy different setsof objectives. This leads to the development of numerous simulator specific models of the same basiccomponent. When component models are developed with different objectives and with unspecified deg
17、rees offidelity, it is difficult to capture component interactions that allow system trade-off investigations and thus,system design optimization. With the need to produce more cost-effective designs, the automotive industry is ready for the development ofthe Model Specification Process Standard.1.2
18、 PurposeThe Model Specification Process Standard is intended to define a common set of standards indefining model requirements for automotive electrical/electronic and mechatronic components. Theserequirements include functional specifications, their intended applications and the deliverables.1.3 Mo
19、del DevelopmentThis standard provides a guide for writing a simulation model specification by the enduser, known as the Requester, and is detailed in the Model Specification Process shown in Figure 1.The general process steps are:a. The Requester requires a component model to perform system simulati
20、ons and submits thecomponent specification based on this standard to the component supplier, known as the Producer.b. The Producer receives the model specification and, possessing detailed knowledge of theircomponent, develops a specific component model. This model can be developed from the ground u
21、por it can be developed from generic component models that are assembled to provide the properperformance. These generic component models can be developed by the CAE simulator supplier orby other component manufacturers.c. The Producer validates the specific model against the Model Specification and
22、 delivers the model tothe Requester.d. The Requester receives the requested model and performs the necessary system simulations.SAE J2546 Issued FEB2002-4-FIGURE 1SIMULATION MODEL DEVELOPMENT UNDER THEMODEL SPECIFICATION PROCESS STANDARD SAE J2546 Issued FEB2002-5-This process has the benefits of ha
23、ving a common vocabulary and standard interpretation of what is beingrequested and what will be delivered. Essentially, this Standard improves the communication between thesystem integrators and the component manufacturers in the automotive industry and will enable thedevelopment of automotive syste
24、ms that represent high customer value.This document will focus on developing the model requirement guidelines (highlighted oval in Figure 1) and thiswill allow the development of the SAE Commodity Model Standards.1.4 ApplicationThis standard provides a guide for the development of model request spec
25、ifications on acommodity-by-commodity basis. Each request specification describes the fundamentals of commoditybehavior and contains a general “request form.” This request form in turn contains pre-defined checklist tableentries for feature/level options as well as placeholders for free-form text de
26、scriptions, graphics and otherrequest-dependent information. A model Requester can then fill out a “blank” form for a given commodity tospecify the level of detail and desired functionality that is expected for a generic model of a particular device. Amodel Requester can also request characterizatio
27、n of an existing generic model to make a model of a specificcomponent or part number.FIGURE 2HIERARCHY OF COMMODITY MODEL SPECIFICATIONSIN RELATION TO DEFINED STANDARDSSAE J2546 Issued FEB2002-6-2. References2.1 Related PublicationsThe following publications are provided for information purposes onl
28、y and are not arequired part of this specification.2.1.1 IEEE PUBLICATIONSAvailable from ANSI, 25 West 43rd Street, New York, NY 10036-8002 or Web serverhttp:/web.ansi.org, or http:/standards.ieee.org.IEEE Std 1076.1-1999IEEE Standard VHDL Analog and Mixed Signal ExtensionsIEEE Std 1076.4-1995IEEE S
29、tandard for VITL Application-Specific Integrated Circuit-ASICIEEE Std 1364-1995IEEE Standard Hardware Description Language Based on VerilogIEEE Std 1499-1998IEEE Standard Interface for Hardware Description Models of Electronic ComponentsIEEE Std 1481-1999IEEE Standard for Integrated Circuit (IC) Del
30、ay and Power Calculation System2.1.2 RELATED MODELICA INFORMATIONModelica and the Modelica Association, http:/www.modelica.org/documents.shtml.The object-oriented modeling language Modelica is designed to allow convenient, component-orientedmodeling of complex physical systems, e.g., systems contain
31、ing mechanical, electrical, electronic, hydraulic,thermal, control, electric power or process-oriented subcomponents. The free Modelica language, freeModelica libraries and Modelica simulation tools are available, ready-to-use and have been utilized indemanding industrial applications, including har
32、dware-in-the-loop simulations. The development andpromotion of Modelica is organized by the non-profit Modelic Association.3. Definitions3.1 AccuracyThe numerical closeness of fit of model behavior in simulation, to target data from the real world.3.2 AlgorithmA formal recipe for solving a specific
33、type of problem.3.3 AnalysisExtracting behavior from description.3.4 ArgumentA piece of information that can be assigned or “passed” to an instance of a model prior tosimulation. An avenue for setting or passing a parameter or a variable.3.5 BehavioralDescriptive of a model designed around results t
34、hat represent physical behavior and internalworkings of a device. See also Functional.3.6 ConnectionA modeling artifact that represents communication of data or signals into or out of other modelcomponents such as junctions, blocks, or circuit components. For electrical circuit models, instances of
35、acomponent are embedded into a design document or netlist with their pins or connection points linked by nets.3.7 Connection PointAn external linkage point on a model, usually corresponding to a port, terminal, connectoror cavity on the physical device. In most cases, connection points must be attac
36、hed to one or more externalcomponents for a valid simulation.3.8 Connection TypeThe specific technology or character of a connection point on a model, defining theallowable connections between models. The type may determine the physical character of a connection, suchas electrical, thermal, mechanic
37、al or hydraulic, or it may identify a particular simulation technology, such asdigital, signal flow or conserved.3.9 ConvergenceComputing a models behavior with acceptable accuracy. Also, solving an implicitmathematical expression until the achieved result agrees with an extrapolated result within s
38、ome specifiedtolerance. The criterion by which a solution is accepted.SAE J2546 Issued FEB2002-7-3.10 DegradationA dependence of a device property on previous operation of a device.3.11 DistributionA non-time series of data values. The independent variable could be frequency, location,deviation, etc
39、.3.12 DependenceA characteristic relationship between variables.3.13 DocumentationThe documentation of a model explains to the user the principles of the models operationand defines its proper use and limitations. Some documentation may be contained in the template file itself inthe form of comments
40、, but usually these must be supplemented with a separate document.3.14 Dynamic Thermal EffectsA modeling technique including ambient temperature, induced heating and heattransfer from the device to ambient. The resulting device temperature directly affects the electrical, mechanicalor other behavior
41、 of the model. See also Static Thermal Effects, Temperature-dependent Effects and MutualThermal Effects.3.15 FeatureAn aspect of an objects nature captured in a model, and the capability to control or acquire thataspect in simulation.3.16 Feature LevelFeature Level classifies how an individual featu
42、re of a model can be applied.3.17 FidelityThe degree to which a representation, such as a model, captures the nature of the real object beingrepresented.3.18 Flat ModelA model that has no hierarchical structure, and which makes no use of subsidiary models, hencethe opposite of macromodel.3.19 FlowA
43、channel for data transfer within or among models during simulation.3.20 FunctionalDescriptive of a model designed to statically or dynamically represent its outputs as functionallydependent on its inputs, without regard for the physical processes involved. See also Behavioral.3.21 GenerationConversi
44、on of some other form of energy to thermal energy.3.22 HeuristicAn adaptive framework for solving a class of problems.3.23 HierarchyUse of the relationships and dependencies amongst the elementary components of a system as abasis for allocating functions and their associated higher levels of abstrac
45、tion such as Subsystems.3.24 High-levelRefers to levels of abstraction in a model that represent reduced functional specificity and detail;opposite of Low-level.3.25 InstanceAn instance is a single use of a model in a design, analogous to a subroutine call. Each instanceidentifies its parent templat
46、e, its own unique identifier, the interface links to the design, and values for itsattributes.3.26 InterfaceAn element of a model which offers transfer of data into and out of the model during simulation.Compare to Connection Point.3.27 LinearModel characteristics that produce outputs which are dire
47、ctly proportional to inputs and give additiveresults from additive inputs. See also Non-linear.3.28 Low-levelRefers to levels of abstraction in a model that represent increased functional specificity and detail;opposite of High-level.SAE J2546 Issued FEB2002-8-3.29 MacromodelA simulation model made
48、up primarily or entirely of subsidiary models, with few or nomathematical or logical expressions at the immediate level of model definition.3.30 MessageA text string emitted by a model during simulation to signify the occurrence of some significantevent.3.31 ModelA formal representation of a compone
49、nt or system which can be used to compute its expectedbehavior under specified conditions.3.32 Model ConstructionA model can be built in a variety of ways: a. Write behavioral equations or algorithms in a modeling language.b. Write calls to existing models in a modeling language.c. Draw diagrams in modeling software using predefined symbols linked to behavioral descriptions.d. Capture certain behavior heuristically from actual parts or from other simulations.3.33 Model ProducerThe component or system Model Producer who, because of t
