As the title may hint, this post will feature another of my German Language Attempts. (1) Today I want to address a thorny issue: how does company A work with company B in a Model-Based Design context? How do you share and protect intellectual property while taking advantage of all of the benefits of Model-Based Design?
Requirements, ICD, and Models
In a traditional development environment, an OEM would provide their vendor with a set of requirement documents (2) which may or may not include an ICD. The difference with Model-Based Design are the Models. (3)
There are three ways that models impact the OEM / Vendor relationship. (4)
- Model as test harness: The OEM can provide plant and test harness to validate the behavior of the vendors model.
- Model as requirement (5): The model can act as a second layer of requirements, the executable spec.
- Model for integration: The model can be used to provide an integration harness with the larger system.
Each of these three items enable faster development by having fewer mistakes in hand off and enabling early verification.
What is “new” with Models
There is additional information required when exchanging models instead of code(6) or object files. It is the associated meta data of the models that needs to be exchanged. These are the “new” things that needs to be specified up front.
- What are the model configuration settings
- How do you store data (parameters)
- What is your architectural approach
- Modeling standards…
I have a secret
The final question with OEM / Vendor relationships is IP; how do you exchange models without giving away the secret sauce? Within the MATLAB / Simulink environment there is the ability to create protected models that can be used to generate code and simulate the model without giving away the “sauce”.
Auf Deutsch!
Ja, es ist die Zeit fur eine Deutsch sprachige Version des Blogs. Die Frage von Heute ist, “Wie arbeite Büro “A” mit Büro “B” und Model-Based Design?” Wie teilen Sie Modelle und schützen gleichzeitig das geistige Eigentum? Können Sie dies tun, ohne die Vorteile des MBD zu verlieren?
Anforderungen, ICD, and Modelle
In einer traditionellen Entwicklungsumgebung würde ein OEM seinem Lieferanten eine Reihe von Anforderungs dokumenten zur Verfügung stellen, die ein ICD enthalten können oder auch nicht. Der Unterschied zum modellbasierten Design sind die Modelle.
Das sind drei Möglichkeiten, wie sich Modelle auf die Beziehung zwischen OEM und Lieferant auswirken.
- Modell als Testgeschirr: Der OEM kann Anlagen und Testgeschirre zur Verfügung stellen, um das Verhalten des Modells des Herstellers zu validieren.
- Modell als Anforderungen: Das Modell kann als zweite Anforderungsschicht, die ausführbare Spezifikation, fungieren.
- Modell fur integration: Das Modell kann verwendet werden, um einen Integrationskabelbaum mit dem größeren System bereitzustellen.
Jeder dieser drei Punkte ermöglicht eine schnellere Entwicklung, da sie weniger Fehler in der Hand haben und eine frühzeitige Überprüfung ermöglichen.
Was ist “neu” an Modellen?
Beim Austausch von Modellen anstelle von Code- oder Objektdateien sind zusätzliche Informationen erforderlich. Es sind die zugehörigen Metadaten der Modelle, die ausgetauscht werden müssen. Dies sind die “neuen” Dinge, die im Vorfeld spezifiziert werden müssen.
- Was sind die Einstellungen der Modellkonfiguration
- Wie speichern Sie Daten (Parameter)
- Was ist Ihr architektonischer Ansatz?
- Modellierung von Standards…
Ich habe ein Geheimnis
Die letzte Frage bei den Beziehungen zwischen OEM und Lieferanten ist das geistige Eigentum; wie tauscht man Modelle aus, ohne die geheime Soße zu verraten? Innerhalb der MATLAB/Simulink-Umgebung gibt es die Möglichkeit, geschützte Modelle zu erstellen, die zur Codegenerierung und Simulation des Modells verwendet werden können, ohne die “Soße” zu verraten
Footnotes
- As I think about “translation,” for languages or code, I ponder what is lost in translation, through miss communication, transcription errors, and “missing content”. The value of the “Model-Centric” approach to development; without the chance for those errors, becomes clear.
- More often than not, when requirement documents are handed off it is an iterative process with several back and forths before the requirements are finalized.
- I highly recommend taking a look at the NASA site on model rockets, not only is it a very good primer on rocketry in general, it is also filled with a joy of understanding.
- I remember playing “3 or more” in middle school, eventually we realized it was a solved game and had to invent our own rules.
- The model should not be treated as the only requirement document, rather it acts as a supplement or derived requirements document. It is possible to use the model as the only requirement document, however in that case the requirements model is not what you use for the production.
- It may be more accurate to say there is different information required; when exchanging Code you need to define coding standards, calling rates….