that can easily be achieved through combination of configurations and model complexity) is not feasible.
Allow users to quickly add their own configurations.
Allow users to implement any test data from subsystems, systems, or entire vehicles in the same environment as the models to facilitate the validation process.
Different studies (e.g., fuel efficiency, emissions, drive quality) require different levels of modeling. Throughout a project, the level of model complexity will increase to take into accounts new physical phenomena.
Common nomenclature, including naming convention, units. If nomenclature is not consistent, an automated process should be provided to users to easily integrate any legacy code into the agreed upon format.
Common model organization to facilitate interactions of different expert models. For example, consistent format between controllers and plant would allow integration between both areas of expertise.
Model compatibility check. When used in a large organization, users do not know what models are compatible with each other. For example, a particular gearbox should be used along with a specific torque converter. Using another combination could lead to a software crash—or worse—erroneous results. While the original developers are aware of the potential issue, it is necessary to enforce that when one model is used, it is in conjunction with the other one.
While most software companies claim to be able to model any particular plant with different levels of accuracy, some software packages are used mainly for specific applications. As a consequence, different experts will use different packages to model specific plants. One needs to have a plug-and-play platform that allows the user to:
Integrate any legacy code from any software package and
Run all models in the same environment or through co-simulation.
The graphical user interface (GUI) should be able to allow users to quickly set up different simulations, including:
Select architecture, model, and data
Check model compatibilities to avoid crash or erroneous results
Select simulation type, including component evaluation, vehicle fuel efficiency, or drive quality
When evaluating specific technologies, having consistent processes is critical for proper comparison. Differences in the definitions of processes could lead to discrepancies in results, which could become a significant issue for regulatory purposes. For example, the definition of the term “validation” varies significantly from one engineer to another. In addition clear definition of generic processes (e.g., calibration, validation, tuning) for major tasks throughout a company will lead to increased productivity.
Users should have the ability to easily modify any processes or implement new ones. One could assume that specific processes would be developed and agreed upon for validation, report generation, and so forth for regulatory purposes.
The GUI should allow users to quickly analyze the simulation.
Predefined calculation. Since most tools only record efforts (e.g., torque, voltage) and flows (e.g., rotational speed, current), existing calculations should allow users to quickly calculate powers, energies, efficiencies, and so forth.
Predefined plots should be available to quickly analyze the operating conditions of each component or control strategies.
Energy balance information should be available.
Reports should be automatically generated.
All results should be saved along with the assumptions and any files required to rerun the simulation.
Any existing calculation, plot, or report should be easily modified by users or new ones should be implemented.
As discussed previously, linkage with other tools is compulsory to properly integrate detailed legacy models. While numerous tools exist, the list should include at a minimum MathWorks toolboxes, GT-Power, AMESim, TruckSim, ADAMS, and AVL DRIVE.