Vehicle simulation has been referred to several times in this report as part of the fuel consumption assessment and certification process and is described in Chapter 3 as already part of Japan’s heavy vehicle fuel consumption rules. Any simulation relies on the availability of accurate submodels or good-quality test data from the components and on accurate portrayal of the physical and control linkages between the components.
Several key requirements are necessary to answer both industry needs to accelerate the introduction of advanced technologies and regulatory needs to evaluate benefits in the most cost-effective manner.
The simulation tool should provide a set of default models, processes, and postprocessing, but also allow users to integrate any legacy code. Indeed, future regulations might recommend that companies use the same assumptions but might also give the option to use legacy codes (e.g., engine and vehicle models) that have been internally developed. Using the same models regardless of the technology considered might penalize a particular company. However, if proprietary models are used, a validation process should be clearly defined to ensure their accuracy under specific operating conditions.
Due to the large number of power train configurations, which will continue to increase with hybrid electric vehicles, the tool should also be able to quickly simulate any drivetrain configurations. Finally, all the physical equations and control parameters should be open source, at least to the regulator, to ensure transparency of the process. It may be necessary to require that proprietary codes be available to the regulatory body either as soon as they are used for regulatory compliance or after some waiting period.
A review of currently available software reveals that, while the tools all provide a set of existing models, each has existing limitations. Some of the existing tools do not represent realistic vehicle behavior (e.g., ADVISOR), are not open source (e.g., AVL CRUISE, GT-DRIVE, AMESIM) or cannot be compiled to perform model-based design (MBD; e.g., AVL CRUISE), or linkage with database management is not available or incomplete.
Most of the models used throughout the industry to simulate fuel consumption are based on steady-state look-up tables representing the losses of the components. Table G-1 lists the main maps for each component. Some of the look-up tables listed can also be multidimensional (e.g., the transmission will have different maps for each gear, the electric machine losses and maximum torque might depend on voltage). The models also require additional parameters such as mass, inertia, ratios, and fuel characteristics.
Most of the parameters can be directly obtained from manufacturers’ specifications. However, some, like tire losses, require specific testing. Additional testing is also required to characterize the losses of the different components. While some of the test procedures are well characterized, others remain different from one manufacturer to the next and consequently should be clearly defined.
TABLE G-1 Main Vectors for Component Models
|
Component |
X-Axis |
Y-Axis |
Z-Axis |
|
Engine |
Speed |
Torque |
Fuel Rate |
|
|
Speed |
Maximum torque |
|
|
|
Speed |
Closed throttle |
|
|
|
|
Torque |
|
|
Transmission |
Speed |
Torque |
Efficiency |
|
Final drive |
Speed |
Torque |
Efficiency |
|
Electric machine |
Speed |
Torque |
Efficiency |
|
|
Speed |
Continuous torque |
|
|
|
Speed |
Maximum torque |
|
|
Energy storage |
State-of-charge |
Open-circuit voltage |
|
|
|
State-of-charge |
Internal resistance |
|
Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 221
G
Vehicle Simulation
Vehicle simulation has been referred to several times in cannot be compiled to perform model-based design (MBD;
this report as part of the fuel consumption assessment and e.g., AVL CRUISE), or linkage with database management
certification process and is described in Chapter 3 as already is not available or incomplete.
part of Japan’s heavy vehicle fuel consumption rules. Any Most of the models used throughout the industry to
simulation relies on the availability of accurate submodels or simulate fuel consumption are based on steady-state look-up
good-quality test data from the components and on accurate tables representing the losses of the components. Table G-1
portrayal of the physical and control linkages between the lists the main maps for each component. Some of the look-up
components. tables listed can also be multidimensional (e.g., the trans-
Several key requirements are necessary to answer both mission will have different maps for each gear, the electric
industry needs to accelerate the introduction of advanced machine losses and maximum torque might depend on volt-
technologies and regulatory needs to evaluate benefits in the age). The models also require additional parameters such as
most cost-effective manner. mass, inertia, ratios, and fuel characteristics.
The simulation tool should provide a set of default mod- Most of the parameters can be directly obtained from
els, processes, and postprocessing, but also allow users to manufacturers’ specifications. However, some, like tire
integrate any legacy code. Indeed, future regulations might losses, require specific testing. Additional testing is also re-
recommend that companies use the same assumptions but quired to characterize the losses of the different components.
might also give the option to use legacy codes (e.g., engine While some of the test procedures are well characterized,
and vehicle models) that have been internally developed. Us- others remain different from one manufacturer to the next
ing the same models regardless of the technology considered and consequently should be clearly defined.
might penalize a particular company. However, if proprietary
models are used, a validation process should be clearly
defined to ensure their accuracy under specific operating
conditions.
Due to the large number of power train configurations,
TABLE G-1 Main Vectors for Component Models
which will continue to increase with hybrid electric vehicles,
the tool should also be able to quickly simulate any drivetrain Component X-Axis Y-Axis Z-Axis
configurations. Finally, all the physical equations and control Engine Speed Torque Fuel Rate
parameters should be open source, at least to the regulator, Speed Maximum torque
to ensure transparency of the process. It may be necessary to Speed Closed throttle
Torque
require that proprietary codes be available to the regulatory
body either as soon as they are used for regulatory compli- Transmission Speed Torque Efficiency
ance or after some waiting period. Final drive Speed Torque Efficiency
A review of currently available software reveals that,
Electric machine Speed Torque Efficiency
while the tools all provide a set of existing models, each Speed Continuous torque
has existing limitations. Some of the existing tools do not Speed Maximum torque
represent realistic vehicle behavior (e.g., ADVISOR), are not
Energy storage State-of-charge Open-circuit voltage
open source (e.g., AVL CRUISE, GT-DRIVE, AMESIM) or State-of-charge Internal resistance
OCR for page 221
TECHNOLOGIES AND APPROACHES TO REDUCING THE FUEL CONSUMPTION OF MEDIUM- AND HEAVY-DUTY VEHICLES
VEHICLE SIMULATION TOOL REQUIREMENTS FOR • Duplication of systems without duplication of models
REGULATORY USE stored. For example, a wheel model should be reused
numerous times without storing it several times under
In a world of growing competitiveness, the role of simula-
different names, which would make versioning man-
tion in vehicle development is constantly increasing. Because
agement difficult.
of the number of possible advanced power train architectures
• Location of expert models in a single site. For example,
that can be employed, development of the next generation
an engine system comprised of control, actuator, plant
of vehicles requires accurate, flexible simulation tools. Such
and sensor models, and initialization file, by being lo-
tools are necessary to quickly narrow the technology focus
cated under the same folder, would facilitate its transfer
to those configurations and components that are best able to
to another expert.
reduce fuel consumption and emissions.
• Open source of the plant and control models (rather
With improvements in computer performance, many
than compiled) to facilitate understanding of the as-
researchers started developing their own vehicle models.
sumptions and the modifications of equations to model
But often computers in simulation are used only to “crunch
new phenomena.
numbers.” Moreover, model complexity is not the same as
model quality. Using wrong assumptions can lead to errone-
Maximum Flexibility
ous conclusions; errors can come from modeling assump-
tions or from data. To answer the right questions, users need
With the consistently increasing number of possible
to have the right modeling tools. For instance, one common
power train configurations for medium- and heavy-duty ap-
mistake is to study engine emissions by using a steady-state
plications and the need to select the different level of mod-
model or to study component transient behavior by using a
eling to properly meet different needs (i.e., fuel efficiency,
backward model.
emissions, drive quality), the need to quickly simulate any
Figure G-1 summarizes the main requirements, discussed
application is crucial. A vehicle modeling software should
below, for vehicle simulation tools required to fulfill both
be able to provide the following features:
needs.
• Simulation of subsystems, systems, collections or
Basic Requirements combinations of systems and subsystems (e.g. power
trains), or entire vehicles. Providing a common envi-
Maximum Reusability ronment to different experts (e.g., engine and vehicle
experts) will facilitate the model’s reusability and
While numerous plant and control models exist through-
ensure process consistency (e.g., validation, calibra-
out companies, it is critical that the work performed during
tion).
a project can be reused throughout the companies for future
• Allow any configuration (assembly of systems) to be
applications. Several approaches are necessary to achieve
quickly modified and built automatically. For mainte-
this goal:
nance purposes, saving hundreds of models (a number
FIGURE G-1 Vehicle modeling tool requirements.
Figure G-1 Vehicle modeling tool requirements.eps
bitmap
OCR for page 221
APPENDIX G
that can easily be achieved through combination of • Select architecture, model, and data
configurations and model complexity) is not feasible. • Check model compatibilities to avoid crash or errone-
• Allow users to quickly add their own configurations. ous results
• Allow users to implement any test data from sub- • Select simulation type, including component evalua-
systems, systems, or entire vehicles in the same tion, vehicle fuel efficiency, or drive quality
environment as the models to facilitate the validation
process.
Generic Processes
When evaluating specific technologies, having consistent
Selectable Complexity
processes is critical for proper comparison. Differences in the
Different studies (e.g., fuel efficiency, emissions, drive definitions of processes could lead to discrepancies in results,
quality) require different levels of modeling. Throughout a which could become a significant issue for regulatory pur-
project, the level of model complexity will increase to take poses. For example, the definition of the term “validation”
into accounts new physical phenomena. varies significantly from one engineer to another. In addition
clear definition of generic processes (e.g., calibration, valida-
• Common nomenclature, including naming convention, tion, tuning) for major tasks throughout a company will lead
units. If nomenclature is not consistent, an automated to increased productivity.
process should be provided to users to easily integrate U sers should have the ability to easily modify any
any legacy code into the agreed upon format. processes or implement new ones. One could assume that
• Common model organization to facilitate interactions specific processes would be developed and agreed upon for
of different expert models. For example, consistent validation, report generation, and so forth for regulatory
format between controllers and plant would allow purposes.
integration between both areas of expertise.
• Model compatibility check. When used in a large
Results Visualization
organization, users do not know what models are
compatible with each other. For example, a particular The GUI should allow users to quickly analyze the
gearbox should be used along with a specific torque simulation.
converter. Using another combination could lead to a
software crash—or worse—erroneous results. While • Predefined calculation. Since most tools only record
the original developers are aware of the potential issue, efforts (e.g., torque, voltage) and flows (e.g., rotational
it is necessary to enforce that when one model is used, speed, current), existing calculations should allow us-
it is in conjunction with the other one. ers to quickly calculate powers, energies, efficiencies,
and so forth.
• Predefined plots should be available to quickly analyze
Code Neutrality
the operating conditions of each component or control
While most software companies claim to be able to model strategies.
any particular plant with different levels of accuracy, some • Energy balance information should be available.
software packages are used mainly for specific applications. • Reports should be automatically generated.
As a consequence, different experts will use different pack- • All results should be saved along with the assumptions
ages to model specific plants. One needs to have a plug-and- and any files required to rerun the simulation.
play platform that allows the user to: • Any existing calculation, plot, or report should be
e asily modified by users or new ones should be
• Integrate any legacy code from any software package implemented.
and
• Run all models in the same environment or through
Linkage with Other Tools
co-simulation.
As discussed previously, linkage with other tools is com-
pulsory to properly integrate detailed legacy models. While
Graphical User Interface
numerous tools exist, the list should include at a minimum
MathWorks toolboxes, GT-Power, AMESim, TruckSim,
Setup Simulation
ADAMS, and AVL DRIVE.
The graphical user interface (GUI) should be able to allow
users to quickly set up different simulations, including:
OCR for page 221
TECHNOLOGIES AND APPROACHES TO REDUCING THE FUEL CONSUMPTION OF MEDIUM- AND HEAVY-DUTY VEHICLES
Database Version Control
As models and data evolve with time owing to improved
User Access Control
data and/or algorithms, or even issues such as new modeling
The sharing and distribution of proprietary models can be software version compatibility, the need for version control is
achieved successfully only if their producers can trust that mandatory for auditing and regulatory purposes. Any study
only the proper users will have access to them. User access done with those models needs to specify which version was
control is the cornerstone of that trust. used to ensure 100 percent traceability of the results.
User access control can be used in two ways: M oreover, version control can also be used intra-
enterprise as a way to get feedback on the original designs.
• Intra-enterprise, to define the access at each process For example, the model producer can follow which modifi-
steps. For instance, during the design stage, only the cations were needed to his model during the calibration and
design team can access the model. Once a version is validation process, which can then be used to create a better
ready, access can be granted to a larger group, such as model next time. Version control can also be used to locate
calibration, testing, and so forth. the original designer to get more information about some of
• Extra-enterprise, to define the access to outside users, the model.
including suppliers, regulatory committees, and so User access control applies on versioning as well. Some
forth. users should have access to all model versions, when some
others have access only to the latest version and others can
Access control should be of at least four types: only see the history.
• Producer, for the people who can add and/or modify
Database Search
models and data on the database.
• Consumers with full access, for people who can down- To maximize the reusability of models, any user should be
load the models and data to run on their computers, but able to search for an existing one available to them. Search
not modify them (or at least not upload them on the should be available on name and versions of the files, as well
database). as specific criteria, such as, engine technology, displacement,
• Consumers with restricted access, who can only run and wheel radius.
the models remotely on a dedicated server (no access The search should also be possible by specific vehicle or
to the models or data themselves). project, so that all of the models and data used for a specific
• Administrator, who manages access control for every- application can be found together and eventually run or
one. downloaded on the user’s computer.
Only the models and data that the user has access to
Users can also be a combination of these types. For ex- should be returned in the search query. As an optional func-
ample, some people creating models may need to access ex- tionality, the search could inform the user that other models
isting ones, and consumers with full access on some models exist but are not available and could provide the coordinates
may have only restricted access on others, or they can access of people to contact to request their access.
only low-fidelity versions of some models.
SINGLE VERSUS MULTIPLE TOOLS SELECTION FOR
REGULATION
Enterprise-Wide Solution
Another requirement for the sharing and distribution of Numerous tools are currently being used by companies,
proprietary models is their enterprise-wide accessibility, in- both internally developed and commercially available. For
cluding for producer and consumer teams spread across the regulatory purposes, consistency between all approaches
country or even the world for some global companies—for is critical for a fair comparison. As a result, while legacy
example, a control design team can have members in the code shall be used, a single platform is necessary to ensure
United States and England, or a model calibration and valida- proper integration of the different systems. Indeed, due to
tion team might be located hundreds of miles from the model the large number of companies involved, the models used
design team. to simulate a specific application will most likely come
Up-to-date models should be accessible to all people who from numerous sources. Common tool and formalism are
have the right access, wherever they are located. then critical. As shown in Figure G-2, the lack of common
This constraint requires a unique and secure point of ac- nomenclature makes reusability of models among companies
cess for all users. However, there can be one point of access very cumbersome.
for intra-enterprise use only in each company and another
global one outside, specifically for regulatory purposes.
OCR for page 221
APPENDIX G
FIGURE G-2 Different nomenclatures within each company currently make model exchange very difficult.
Figure G-2 Different nomenclatures within each company curre.eps
bitmap
OCR for page 221