- Component delivery
- ICD compliance
- ICD mismatch
- Naming collisions
- Component initialization
- Simulator configuration
- Simulator version
- Location independence
- Shared parameters
- Data capture
You may have already noticed that none of these issues are created during the integration effort. Instead, all of these problems are created upstream earlier in the project, but do not manifest themselves until your team tries to integrate the components.
This observation explains why my frustration was magnified in distributed projects. When receiving components from other groups, I would often encounter one or more of these issues. Whenever I encountered such a problem, it would require a negotiation with the supplying group that could be lengthy and error-prone. This negotiation could be tricky because I did not have managerial control over the other groups.
This frustration was the impetus behind the SystemBlend™ application suite, which we created to address all of these problems in a simple, unified way.
This post addresses the first subtopic on integration: Component delivery.
Component Delivery
The first step in integrating components from other organizations is to receive them. In my previous experience, this was a significant source of frustration. The biggest offenders were
- Missing resources, and
- Mismatched resources.
Missing Resources
Basically, missing resources are files that are needed by the model for execution, but are not included with the component. The most common forms of this are:
- Missing data files,
- Missing initialization scripts, and
- Missing libraries.
This is not always because engineers are careless or incompetent; I have received incomplete components from very professional and diligent engineers. The process of identifying all needed resources is simply error-prone.
This issue can cost a lot of time. When an incomplete component is first delivered, sometimes your team can identify the missing resource, sometimes you need help from the supporting group. Either way, once you get the identified resource, there is a chance that you will try integrating it again, only to discover other missing resources. This is usually resolved in one or two tries, but I’ve seen it last much longer.
This issue would usually occur either during the initial delivery or when a major update is delivered.
If the group supplying the component has a continuous integration process in place, this issue will be reduced or eliminated. Unfortunately, many simulation groups have not implemented such a process. Because you do not have managerial control over the other groups, it would be very difficult to put such a process in place.
Mismatched Resources
Mismatched resources are files that are delivered with the component, but don’t work together. Again, this is not always a matter of incompetence; it is a reflection of how difficult it can be to build a cohesive set of resources.
For example, a simulation component requires that a particular parameter be initialized, but the initialization scripts don’t set the parameter.
I haven’t seen this occur very often with the initial delivery of a component; I’ve seen it mostly when the supporting organization supplies an update to the component. For example, an organization will update and deliver a block diagram, and forget that some of the initialization scripts were updated to support the change.
A Combination of The Two
A few times I have seen these two issues gang up against me. It goes something like this:
- A supporting group delivers the initial component to your group.
- Your group begins working with the component to integrate it.
- The supporting group continues development of the component.
- Your team identifies a missing resource.
- The supporting group provides the missing resource that supports their updates to the component, but is incompatible with the initial delivery.
Without the proper tools, both of these issues will continue to recur as the overall project develops and evolves. The different groups will eventually develop an ad-hoc workflow that reduces the frequency of these problems, but they will still happen.
SystemBlend™
SystemBlend™ addresses these issues by testing the packaged component prior to delivery.
Component developers use the second application in the suite, ComponentGuide. ComponentGuide has a step to ‘package’ the component, and then an automated step to test the component.
To package the component, the developer simply points to the file system directory that contains the component, and then identifies the file that is the initialization script. ComponentGuide then stores this directory and its subdirectory structure internally, along with notes on which file is the initializer.
When the component developer elects to deliver the component to your group, ComponentGuide automatically performs a series of verification tests. This includes:
- Instantiating the entire component in a new location from its internally stored resources,
- Running the initialization script, and
- Running both an automatically generated test harness and a user-supplied unit test.
When running the ‘rehydrated’ component within the SystemBlend™ environment, Simulink will not know about the rest of the developer’s environment, ensuring that the resources are complete and consistent.
These automated tests occur every time the supporting group delivers a component or an update, ensuring every delivery and update is complete. Of course, this means that some resources will be delivered repeatedly, but in these days of cheap disks and high-speed connections, that is usually not a concern.
Other Articles in this Series:
- Part 1: Project Launch
- Part 2: Updating Components
- Part 3: Adding Components
- Part 4: Splitting Components
- Part 5: Replacing Components
- Part 6: Component Delivery
- Part 7: Imprecise ICDs
- Part 8: Misinterpreted ICDs
- Part 9: Naming Collisions
- Part 10: Simulation Parameters
- Part 11: Simulator Configuration
- Part 12: Location Independence
- Part 13: Shared Parameters
- Part 14: Data Capture
- Part 15: Architecture Updates
- Part 16: Deprecating Components
- Part 17: Project End-of-Life
Note: This post has been updated with links to other posts in the series