The SSP Traceability Workflow Guide is a supplementary documentation to the SSP Traceability Specification 1.0. While the SSP Traceability Specification 1.0 essentially describes a data format for STMD files in the sense of a normative document, the SSP Traceability Workflow Guide addresses how and in which way Glue Paerticles are used in industrial practice. It thus addresses topics and answers questions that the SSP Traceability Specification 1.0 as a normative document cannot address and answer.
This is a development version of the SSP Traceability Workflow Guide. Releases and issues can be found on github.com/PMSFIT/SSPTraceabilityGuides.
1. Introduction
Based on typical scenarios in the simulation of complex systems, the SSP Traceability Workflow Guide intends to show how simulation processes and model creation processes may be documented using the Glue Particle approach. A Glue Particle is an XML file in which all simulation or model creation relevant resources and information are described or linked. The goals of the glue particle approach are:
-
Traceable documentation of simulation and modeling processes for retrospective analyses
-
Replacement of order-relevant information and resources for simulation and modeling processes in cross-company collaboration
-
Transfer of simulation or modeling process relevant information and resources within the company between departments or IT tools
-
Reuse of simulation-relevant resources and informtion (e.g., models, parameters, tools, etc.) for simulation repetition
-
Reuse resources such as simulation models or parameters for similar simulations.
Align these gpals with the scenarios in chapter Chapter 3
The SSP Traceability Workflow Guide intends to provide support on how to handle Glue Particles with the focus on workflows and processes in industrial practice. In industrial practice topics come into focus that go beyond the scope of a data format specification, including the topics in the following list.
-
Consistency and quality assurance
-
Glue Particle data management
-
Dealing with complex multi Glue Particle constellations
-
Retrospective interpretation of Glue Particles
-
Reuse of Glue Particles
-
Exchange of Glue Particles between IT tools and systems
-
Cross-company exchange of Glue Particles
-
and many more
This is where the SSP Traceability Workfkow Guide comes in. The Workflow Guide addresses these issues and provides recommendations for handling Glue Particles in industrial practice.
1.1. Definition of esential term
In the context of the development of the SSP Traceability Standrd, the terms scenarios, workflow, process and use case are frequently used. These terms will be explained and distinguished from each other but also positioned in relation to each other.
Scenario
A scenario describes the situation from a business perspective in which Glue Particles may be used and offer or generate significant added value. The description of a scenario includes the naming of the organization or roles involved as well as the business goals of the organization or roles involved.
The term scenario in this context should not be confused with the term scenario as used in the context of automated and autonomous driving. In automated and autonomous driving, a scenario refers to a complex traffic situation with a number of moving and non-moving objects in the road space and a complex constellation of many boundary conditions in which an automated or autonomous vehicle is to move.
Workflow
The workflow describes how Glue Particle will be used in each scenario and how they may provide and generate the expected added value. The process flow of each scenario is described by at least one, or if necessary, by several alternative or complementary workflows. Essentially, process diagrams and additional textual descriptions are used. Here, the focus is on the process-related handling of the Glue Particle
Use case
A use case describes how the Glue Particle is handled in very specific, narrowly defined situations, or how it is interacted with manually or technically. The main question here is who does what with the Glue Particle and when, and what the respective result of the interaction is. The focus here is on the operational handling of the glue particle.
Process
The term process may be used on different levels and means that interrelated activities, interactions and communications have a certain causal and temporal sequence. In addition, the term may also be part of fixed and thus predetermined terms, such as commissioning process, requirements process or export process. The term process may therefore appear in this documentation in the context of scenarios as well as in the context of workflows and use cases.
1.2. Conventions used in this document
-
The version number of this documentation is to be interpreted according to the Semantic Versioning Specification (SemVer) 2.0.0 [SEMVER200].
-
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 [RFC2119].
1.3. Document structure
Hier zum Schluss noch die Dokumentstruktur einführen
* Glue Particle Approach * Szenarien und Workflows * Use Cases für GP Handlig
2. The Glue Particle approach
The essential core of the Glue Particle approach is the in-process, machine-readable documentation of information about a credible simulation or modeling task in a standardized format.
2.1. Credibble simulation/modeling process
Both a credible simulation process and a credible modeling process are very similar and both
-
have a fixed start in terms of time
-
usually start with defined and communicated goals
-
are completed at a certain point in time
-
are completed upon achievement of the defined goals
-
can be structurally divided into execution phases and execution steps.
2.2. Glue Particle
The task of the Glue Particle is to bundle all relevant information about a credible simulation/modeling process in a standardized format in XML files. This includes, among other things, the inclusion of information about resources used. The inclusion of resources in the Glue Particle may be done in three different ways.
-
Resource information may be written directly into the XML file. This procedure is suitable for single or very few atomic information.
-
The far more elegant way is to outsource the information into own files and to refer to this outsourced information from the Glue Particle file. This is more suitable for a bigger amount of information.
-
A third option is to link the Glue Particle file to relevant resources stored in IT systems.
Figure 1 illustrates these three ways to include resources.
Chapter 4 goes into more detail about these three options.
A credible simulation/modeling process typically goes through the following execution phases, starting with the analysis of the actual objective of the simulation or modeling task and ending with the decision whether this objective has been met.
-
Analysis phase
-
Requirements phase
-
Design phase
-
Implementation phase
-
Execution phase
-
Evaluation phase
-
Fulfillment phase
Therefore, the Glue Particle, which is supposed to document the information about these execution phases, contains seven correspondingly named segments to structure this phase-specific information. In addition, there is a segment with general information about the respective Glue Particle file.
Each execution phase of a credible simulation/modeling process may include one or more execution steps. For example, in the requirements phase,
-
Requirements for models,
-
Requirements on parameters,
-
Requirements to the simulation environment
-
Requirements for simulation integration
-
Requirements for test cases,
-
requirements for quality assurance
may be specified. In addition, a final review of all results of an execution phase and their formal confirmation may be useful. For example, at the end of the requirements phase, there may be a verification of all requirements and their compatibility, as well as the confirmation and release of all requirements. Therefore, in each phase segment there is a final sub-segment that contains information about this verification step.
Therefore, in a Glue Particle File, each phase segment has one or more step segments for the individual execution steps of an execution phase. Each of these step segments again has the same uniform structure. A segment for a step in a phase is structured according to input, procedure, output, rational and life cycle information. [in-GlueParticleStructureSchema] shows the basic structure of a Glue Particle using a section of the STMD XML schema as an example.
It is important to understand what a Glue Particle is and what it is NOT, or what it may and may not be used for.
What is a "Glue Particle"?
-
A Glue Particle is a bundle or compilation of relevant information for a credible simulation/modeling process.
-
A Glue Particle is a file used to exchange information between IT tools and systems (data management systems, authoring systems, etc.).
-
A Glue Particle is a file used to exchange information between organizations (departments, companies, etc.).
What is a Glue Particle NOT?
-
A Glue Particle is NOT a data format used to organize information in IT systems.
-
A Glue Particle is NOT a process format for controlling technical or organizational processes.
2.3. Integration of Glue Particles into the work processes
The Glue Particles may be used both for company-internal documentation to ensure traceability and to support the reusability of information and artifacts as well as for the exchange of information and artifacts across company boundaries. It would be conceivable, for example,
-
for a company-internal department to commission another department within a company for a system simulation
-
or to commision an external service provider to create simulation models in order to carry out a simulation task,
-
or to outsource the execution of the actual simulation to an external computing center.
In all these cases, the Glue Particles serve both
-
to provide or exchange information and artifacts needed to perform the commissioned task or
-
to provide and exchange the documentation on the execution of the task and the documentation of the results.
As an example for a commision, a simulation task may be defined in the context of a component or system development and handed over to a simulation engineer or to a simulation department. As another example, a modelling task may be generated from a simulation task, or to be more specific, from the implementation phase of the simulation task and handed over to a modeling expert. Figure 3 shows schematically how a modeling task is generated from a simulation task and Figure 4 illustrates the role of the Glue Particles in this scenario.
Figure 5 shows schematically how a complete phase or even more that one phase of the credible simulation task is handed over to an external partner.
2.4. Role of Glue Particle in terms of traceabitity
One of the core goals of the Glue Particle approach is the traceability of simulation and modeling processes. This means that it should be retrospectively traceable what was simulated, how it was simulated, which models and which parameters were used for the simulation, which IT tools were used for the simulation and last but not least, which methods were used for the simulation, which assumptions were made and with which rationale these assumptions were made.
All this information is to be bundled in the Glue Particle and with the help of the Glue Particle. The entire simulation or modeling process is covered and the Glue Particle is stored permanently so that it may be consulted at a later point in time if required. The Glue Particle, i.e. the STMD file, is thus the central information carrier for traceability.
2.5. Role of Glue Particle in terms of credibility
In product and system development projects, numerous design decisions are made based on simulation results. If you want to make design decisions with certainty, you may have to trust simulation results. This trust is strongly linked to the credibility of the simulation results and to the credibility of the entire simulation process. A complete high-quality and traceable documentation of the simulation process may significantly and decisively improve the credibility and trust in the simulation process and in the simulation results and thus may ease design decisions.
2.6. Role of Glue Particle in terms of reusability
In system and product development processes it may be necessary to repeat a simulation. This may be an exact repetition or a repetition with slightly modified boundary conditions. In this case, it is not only important to know what was simulated and how (traceability), but it is also extremely helpful if the resources used can be accessed directly. Here, too, a Glue Particle may play an important role, as it supports the reusability of resources.
2.7. Integration of the Glue Particle approach into the SSP standard
The SSP Traceability Specification is a so-called layered standard in the sense of the Systems Structure and Parameterization (SSP) standard of the Modelica Association. In particular, the Glue Particle approach uses the System Structure Package format of SSP. A System Structure Package is a zip archive containing a so-called System Structure Description file (SSD file) and all resources like models and parameter files needed to describe a system structure.
Glue Particles are also packed according to this principle. A Glue Particle for a credibble simulation/modeling process is a zip archive containing at least one SSD file (according to the requirements of the SSP standard) and at least one STMD file. The STMD file represents the actual Glue Particle. If local resources are referenced by the STMD file, they must also be included in the Glue Particle zip archive. When sharing Glue Particles across companies, all external references usually point to files within the zip archive.
Figure 6 shows a typical System Structure Package as specified in the SSP standard specification. The SSD file is mandatory. All othre data files are optional according to the business needs. The meaning of the file extensions are
-
The system structure description (SSD) is a mandatory part of every system structure package that is used to describe hierarchical and functional structures of a whole FMU network.
-
A system structure parameter values (SSV) element is used to describe parameters and external parameter sets that can be applied to an FMU, thus parameterizing it.
-
A system structure parameter mapping (SSM) is used to describe parameter mappings that may be required to parameterize FMUs.
-
A system structure signal dictionary (SSB) is used to describe signals.
All files are encoded in XML.
In order to use the Suytem Structure Package as a standardized container mechanism for carrying Glue Particles along with local file ressources the SSD file must be included in the System Struncture Package archive to remain compatible with the SSP standard. This may be a business compatible SSD file that represents the system being simulated or may also be a "dummy" SSD file that is practically empty with no business related content. The meaning of the file extensions are
-
The STMD file is the core file of the Glue Particle.
-
The SRMD file is a file that describes simulation resources.
-
The SMMD file comprises simulation model medadata, the business related metadata for the Functional Mock-up Unit (FMU).
All files are encoded in XML.
im-SspSystemStructurePackageForGlueParticle illustrates an System STructure Package applied for carrying a Glue Particle.
3. SSP collaboration and traceability scenarios
3.1. Cross-company coupled simulation or modeling processes
3.2. Integrated cross-company simulation and modeling process
3.3. Interdepartmental simulation and modeling processes
3.4. In-house coupling of simulation and modeling relevant IT tools
3.5. Reduction of development and validation effort through reuse
3.6. Company internal evaluation of knowledge by criteria
3.7. Retrospective tracing of simulation and modeling processes
3.8. Extension of SDM infrastructures with SSP traceability management
3.9. Library and market place management for models and parameters
4. Embedding and referencing resources
A Glue Particle provides in several sections three alternative options to include information about resources, e.g., resources for inputs, outputs or procedure information.
-
Resource information may be written directly into the XML file. This procedure is suitable for single or very few atomic information.
-
The far more elegant way is to outsource the information into own files and to refer to this outsourced information from the Glue Particle file. This is more suitable for a bigger amount of information.
-
A third option is to link the Glue Particle file to relevant resources stored in IT systems.
This chapter outlines how these options may be used and when best to use which of these options.
4.1. Embedding resources
Resources are specified using the <stc:Resource> element. To embed information about resources directly in the Glue Particle, the element <stc:Content> must be created within the element <stc:Resource>. Any content may then be created in the <stc:Content> element.
Figure 8 shows how this construct is built up in the Glue Particle XML Schema for a Credible Simulation Process.
Direct embedding of resource information may be useful when the information is very compact and very limited, e.g., for single or very few information. Figure 9 provides an example for embedding resource information by means of a XML element <stc:Content> Element. Note that the source attribute in the XML element <stc:Resource> is not used.
4.2. Referencing external resources
As soon as a larger amount of information is to be specified per resource, it is no longer useful to write it directly into the Glue Particle XML file for several reasons.
-
The file size of a Glue Particle may increase significantly if too much resource information is embedded into a Glue Particle file. This effect would carry over to each new version of the Glue Particle with successive development of a Glue Particle.
-
Referencing resources that are external to the Glue Particle improves the possibilities for resource reuse. In principle, an external resource may be referenced by multiple Glue Particles simultaneously and consistently.
-
Many resources can be expressed in standardized data formats or are available in standardized formats. Therefore, it would be inefficient to recode this information from the standardized data format into a Glue Particle compatible format for embedding. It is more efficient to leave a resource in its standardized data format and thus also facilitate the processing of the information in the collaborative engineering processes.
Basically, two types of resources may be distinguished.
-
File-based resources: These are resources that are available as a file and are added to the System Structure Package, the container for the Glue Particle.
-
Remote ressources: Resources that are managed in a data management system. From the point of view of the Glue Particle, these may also be referred to as remote resources.
Regardless of which type of resource is to be referenced, the URI, i.e. either the relative path to a file within the Glue Particle container or the URL to a resource in a data management system, is written to the source attribute of the XML element <stc:resource>. If the source attribute is missing, the resource is provided inline as contents of the <stc:Content> element, which must not be present otherwise
Figure 10 shows how this construct is represented in the Glue Particle XML Schema for a Credible Simulation Process.
Below are two examples of how the references are implemented.
Figure 11 provides an example for referenced local resource information by means of the attribute source in the a XML element <stc:Resource> Element. Note that there do not exist any <stc:content> elements in the XML element <stc:Resource>.
Beispielcode Remote Resource
Whether file-based resource or a remote resource is used depends on the context. In the following, the respective context-specific advantages and disadvantages are described.
-
When referencing to resources in managed source systems, there is no additional redundancy.
-
Since information in data management systems is usually managed with version accuracy, the reference to resources in source systems significantly improves traceability.
-
Since information in data management systems is usually stored persistently and is specially protected by backup mechanisms, the reference to resources in source systems provides improved security against data loss or undesired data modification.
-
On the other hand, the references to remote resources usually no longer work when the Glue Particle is exchanged across companies, as access to the source system then probably no longer works.
-
There may also be restrictions within the company if a consumer of a Glue Particle does not have access to the source system.
5. Company internal IT tool couplings
Tobe defined
5.1. Synchronious IT tool couplings
Tobe defined
5.2. Asynchronious IT tool couplings
Glue Particle may be used within companies to successively collect information such as inputs, outputs, procedures and their rationales during the simulation process (Credible Simulation Process) for the individual phases and steps of the process and store them in the Glue Particle, thus gradually enriching the Glue Particle.
The Glue Particle is to be carried through the process and the Glue Particle transports information through the IT tool chain. This means that the IT tools and systems used in the simulation process must be able to read or import a Glue Particle and write or export it.
-
An IT tool used in phase x of the simulation process would write resources generated by that tool to the Glue Particle or link resources and then export or save the Glue Particle.
-
An IT Tool used in phase x-1,x+2 etc. of the simulation process would read or import the Glue Particle and may use the resources provided by it.
This type of IT system coupling via the export - import processes is referred to as asynchronous coupling. The IT systems involved do not have a direct interface with each other and are therefore not directly connected. Therefore, both systems do not have to be in operation at the same time.
Figure 12 illustrates the asynchronous system coupling.
By using the Glue Particle to establish an asynchronous coupling of IT tools and systems involved in the process, the number of interfaces required can be reduced compared to synchronous coupling. This reduction effect increases with the number of IT tools and systems involved in the process and the complexity of the information transport through the process.
6. Cross-company exchange of Glue Particle
An exchange of data, especially engineering data, is usually linked to a business relationship between the companies involved, or the need for an exchange of data is conditioned by a business relationship. This is also the case with the exchange of Glue Particles.
A cross-company exchange of information typically couples two different processes using the transferred information. On the one hand, there is a process at the customer’s side, e.g., a simulation process, and on the other hand, there is a process on the contractor’s side, e.g., a modeling process. At the customer’s side, a simulation is carried out as part of a product development and for this simulation the simulation model of a supplied component is required. The simulation model is to be provided by the supplier. The simulation process and the modeling process are linked, for example, by a modeling order or a model request and by the transfer of the model to the customer. <<>> illustrates this exchange constellation on a high level.
7. Use cases for the handling of Glue Particle files
7.1. Re-use of Glue Particles
The re-use of Glue Particles, respectively of STMD files is one of the main applications of the Glue Particle approach. Glue Particles reference resources that are consistent with each other for a given simulation or modeling task. These resources may be simulation models, parameters, test cases, tools used for the simulation, and other relevant resources. The compilation of these resources and additional information documenting procedures, assumptions and simplifications and respective rationales in a Glue Particle represents a considerable added value. This applies especially if a Glue Particle is entirely or partially re-used for nother simulation tasks. Four examples of re-using Glue Particles are introduced here.
-
Re-use of Glue Particles for a simulation of a DC motor with the same objectives, conditions and resources
-
Re-use of Glue Particles for a simulation of a DC motor with the same objectives but aother set of parameters
-
Re-use of Glue Particles for a simulation of a DC motor with the same objectives but another motor model
-
Re-use of Glue Particles for a simulation with the same objectives in another simulation tool environment
7.1.1. Re-use a Glue Particle unchanged
tbd
7.1.2. Re-use a Glue Particle and replace parameters
A repetition of a simulation with another set of parameters requires a replacement of the parameter file by another parameter file in case the parameters are stored in a local digital file. Assuming the new parameter file may be named differently also the resource link must be adapted for referencing the new parameter file. In case the parameters are stored in an IT system, e.g. in a parameter database, only the resource link has to be adapted.
Preconditions
-
The simulation objectives and requirements remain unchanged
-
The design specification for the parameters remains unchanged
Affected CSP sections
The parameters are implemented in the CSP step Implement Parameters (see also ???) of the CSP phase Implement and Asure Quality for Simulation Setup (see also ???) and the implemented parameters are referenced as an outpout of this CSP step. Therefore if the parameters are replaced by other parameters the CSP step Implement Parameter ist primarily affected. Because the parameters have been replaced it is necessary to also check whether the replacement has any influences on the simulation setup integration. Additionally, there may be a formal necessity for re-verifying the information in the Glue Particle section ImplementationPhase in order to assure and conform the simulation setup quality.
Primarily affected CSP sections are
-
Implement Parameters
Co-affected CSP sections are
-
Integrate Simulation Environment, Models, Parameters
-
Assure Simulation Setup Quality
-
Derive Simulation Setup Quality Verdict
The affected CSP sectios are shown in Figure 13.
Pre-state Glue Particle
Relevanter Ausschnitt vom Glue Particle
User Operations
If parameters are replaced, the user must proceed as follows to ensure consistent documentation of the new simulation task.
-
In case the parameters sre provided as a local digital file replace the parameter file with a new parameter file
-
Replace the existing resource link with a new link, either to the new local digital file or to a new target in an IT system
-
Check whether the new parameters are syntactically compatible with the associated model and are semantically valid
-
Document in the Procedure field of the STMD step section ImplementParameter in the STMD phase stection ImplementationPhase the replacement procedure, if applicable, e.g. file physically replaced or file edited
-
Document in the Rational field of the STMD step section ImplementParameter in the STMD phase stection ImplementationPhase the reason for the replacement of the parameters, e.g. simulation with more precised parameters or simulation with upscaled parameters to represent a larger DC motor
-
Check whether the replacement of the parameters has any influences on its integration into the overall simulation setpup
-
Implement all required measures to assure the simulation setup quality with the new parameters
-
Document the assurance of the simulation setup quality in the STMD step section AssureSimulationSetupQuality of the STMD phase section ImplementationPhase.
Tools Functionalities
A tool designed to handle Glue Particles resp. STMD files may support the user in the folliwing activities.
-
Replacement ot the parameters
-
Replacement resp. the editing of the resource link
-
Script-based compability check of the parameters
-
Filling out the Procedure and the Rationale field in the Glue Particle
Derivation chain
It is important that the trace to the original Glue Particle is preserved. Corresponding information should be entered in the STMD section DerivationChain in the STDM section GeneralInformation.
Handling metadata
This use case does not result in any specific additional requirements for handling metadata. The general requirements as documented in chapter ??? apply here.
Data Management Operations When a Glue Particle is revised, a new Glue Particle respectively a new version of the Glue Particle is actually created. The link betwen a Glue Particle and the original Glue Particle might be managed and displayed at the data management level.
Post-state Glue Particle
Relevanter Ausschnitt vom Glue Particle
Post-conditions
-
A new Glue Particle is available
-
The new Glue Particle has a trace to the Glue Particle from which it originated
-
The Glue Particle references new parameters
-
The procedure and the reason of the replacement are documented
-
The integrity of the entire simulation setup with the new parameters has been checked and confirmed according to the requirements of the Credible Simulation Process
7.1.3. Re-use a Glue Particle and replace simulation model
7.1.4. Re-use a Glue Particle and replace tool environment
Glossary
The following list of terms and, where given, abbreviations serves to explain typical technical terms related to the Glue Particle approach. This list explicitly does not represent any technical vocabulary from the engineering context.
| Term | Abbreviation | Explanation |
|---|---|---|
Boundary model |
Models of the elements whose interaction with the core model (SuT) should be taken into account |
|
Core model |
The simulation model that is to represent the system under test. In the case of SW the SW |
|
Credible Modeling Process |
CMP |
|
Credibility documentation |
||
Credibility of simulation |
see chapter CSP |
|
Credible Simulation Process |
CSP |
|
Environment model |
Subset of boundary models: Models of the (non-technical) environment in which a system under test operates (roads, traffic, weather, etc.) |
|
Glue Particle |
entfernen |
|
Intellectual Property |
IP |
|
Model |
in this context always simulation model |
|
Model Identification Card |
MIC |
Standard/recommodation from SystemX for Model Meta Data |
Modeling request |
||
Modeling task |
||
Product Lifecycle Management |
PLM |
|
Quality |
Schauen was in CSP schon definiert ist |
|
Simulation environment |
The "simulation environment" describes the complete tooling that is needed to run and evaluate a simulation (simulator, pre-processing, post-processing, test tool, data- and workflow management, …)without simulation models. |
|
(Simulation environment) module |
Elements of the simulation infrastructure which are used and have to be developed or adapted. this can be done in separate subprocesses (similar to model development process), like pre/post-processing functions |
|
Simulation-based Engineering Task |
SbET |
|
Simulation Model Metadata |
SMMD |
|
Simulation objectives |
||
Simulation request |
||
Simulation setup |
The simulation setup includes all elements needed to run and evaluate a simulation. These are the simulation models, the parameters, the test cases, the simulation environment and their interaction. The interaction is usually described in workflows. |
|
Simulation task |
||
Simulation Task Meta Data |
STMD |
|
Single decision process |
||
System under Test |
SuT |
Determination of what is the system to be considered (DC motor, SW) |
Test case |
Typical applications of the CSP are System Analysis, Optimization and Test. The CSP differs here only in some specific aspects. For better readability, the synonym "test" is used for System Analysis, Optimization and Test. |
|
Verification and Validation |
V&V |
References
-
[RFC2119] Bradner, S.: Key words for use in RFCs to Indicate Requirement Levels. RFC 2119, March 1997. https://www.ietf.org/rfc/rfc2119.txt
-
[SEMVER200] Preston-Werner, T.: Semantic Versioning 2.0.0. https://semver.org/spec/v2.0.0.html
-
[SSP10] Modelica Association: System Structure and Parameterization 1.0. March 2019. https://ssp-standard.org/publications/SSP10/SystemStructureAndParameterization10.pdf
-
[STMD] Modelica Association: SSP Traceability Version 1.0.0-Beta2,unreleased Link hinzufügen
Appendix A: Backlog
-
Using SSD-files to specify models
-
Image for generic illustration of cross-company Glue Particle couplings.
-
Distinction from the internal exchange of Glue Particles
-
Central concepts for cross-company Glue Particle couplings
-
Example: Simulation request to a supplier
-
Example: Transfer of simulation results
-
Example: Model request to a supplier
-
Example: Model handover to customer