Tag: #architecture

In the last post we looked at the characteristics and objectives of modeling architecture.  In this post, we will look at one method for satisfying those requirements.

Shell games, the parent and child relationship

A system level model is built from multiple levels of integration models.

• Functional (child) model: A model that is comprised of function code, e.g. a plant or control model.
• Integration (parent) model: A model that built from multiple functional models.  The integration model does not have functional code but may contain execution order (scheduling) elements.

In this example, there are three functional (child) models; their interface is defined through the use of “ports” and have the descriptive names of “Known_#” and “BUS_#”.  We will look at this convention more in the next section.

The first iteration of the functional (child) model is what is known as a “shell” model.  The inputs and outputs of the shell model should match the defined interface, e.g. the data type (double, int, float or structure) and dimension (scalar, vector).  Further the outputs from the shell model should provide values that are “safe” for other functional components in the system(1)   As the shell model is elaborated the outputs will reflect the actual executable code.

System architecture with unknown interfaces…

For well-established systems the input and outputs from the system will be known ahead of time.  However, for newer projects, the functional interface may not be fully defined.  In this instance buses(2) can be used to provide a flexible interface.  Members of the bus are selected inside of the child model, because of this members can be added to the bus as needed without breaking the interface of other child models.

Rational behind this approach

This approach to developing the system level model has multiple advantages…

1. First, it allows independent development of the functional models.  Engineers are free to develop their model as long as they maintain the functional interface(3).
2. Unit level testing can start with the initial shell model
3. This approach allows system level testing at an early stage of development.
4. This system promotes reuse of components.

Limitations of this approach

Following this approach can lead to inefficient or unclear function interfaces if the engineers keep adding new things into the input and output buses.  This can be avoided by follow through periodic reviews of the interfaces.  I will cover rules for data management in future posts(4).

Footnotes

(1)In this example I show simple constant blocks.  More complex data can be outputs can be created using signal generator blocks.
(2) In the MATLAB / Simulink environment, a bus maps to a C structure.  The bus is members are defined as part of the data dictionary then the model can create instances of the bus.
(3) The reality of development is that at some point in time the functional interface will need to change; a change process should be put into place to account for the change to the bus definition or ports of the system.
(4) As a general rule of thumb buses (structures) should not be more than 2 levels deep (e.g. Structure in Structure) and each root level should have no more than 12 signals. Going beyond this can result in difficult to parse data structures.

In this section, we start our discussion around software architecture.  Taking a broad perspective all software architecture has three attributes

• Components: Components are the fundamental building blocks of all software; they contain the “guts” that enable the software to perform their required functions.  These could be viewed as functions or classes in C/C++ or models in the Simulink environment.
• Connectivity:  Connectivity is how components exchange information (data) with other components.  For example, a function definition in C / C++ or input and output ports in a Simulink model
• Scheduling and execution control: The software architecture allows for (and maybe) the entity that controls the execution of the components.  Note: this is not addressing the low-level O/S scheduling.

So knowing the attributes the next question is “what are the functional objectives?”

1. Facilitates group and individual development workflows:  Individuals should be able to work on the component they are developing with minimal impact/reliance on other people in their group.  At the same time, the group should be able to use components from others at an early stage in development.
2. Provides easy integration of components: The components should be able to easily “connect” with components in both the new model based environment and any existing text based (C) environment.
3. Enables unit and system level testing:  Components should be designed with clearly defined external dependencies and they should be minimized.  At the system level, child models should enable testing early in the design process using shell models.
4. Promotes reuse of components: Developers should be able to reuse components either directly or through some data-driven modification.
5. Is efficient in both execution speed and memory usage:  The decomposition of the system level model into components should balance clarity with efficiency.

The final consideration is stylistic(1), how do you create a model architecture and components that are easy for controls, system and test engineers to understand?  The M.A.A.B. Style Guidelines provide a solid foundation for developing understandable components. In my next blog post, I will start looking at how components fit into system level architectures and how they can be elaborated and tested throughout the development cycle.

Footnotes

(1) While I list the final consideration as “stylistic” it is of the highest importance. As clarity of communication is essential for ensuring reuse (objective 4), ease of integration (objective 2) and allowing group and individual workflows (objective 1).