Capability Pattern: Exchange models, OEM side
DescriptionWork Breakdown StructureTeam AllocationWork Product Usage
Relationships
Context
Description

Figure 1 shows the OEM side of this use case. The integrator gets the Timing Models of the delivered subsystems that are necessary to reason about the integrated system’s timing behavior from his suppliers.

Note that reasoning about the system’s timing behavior works differently in early phases (i.e. vehicle and analysis phase). There, the OEM estimates or guesses timing properties of planned subsystems to compare and choose between different system approaches. However, in this use case we focus on the design and implementation levels. At that levels the system approach has already been chosen and the OEM steers the system development into the desired direction by imposing timing requirements, like time budgets (see separate use case), to his suppliers. However, he is (in his idealized role as integrator) not actively specifying and developing system parts on his own that he has to characterize with respect to their timing characteristics.

Using the timing models of all delivered sub-systems, the OEM can create an integrated timing model of the whole system. Based on this timing model she can validate all timing requirements motivated by the individual functional implementations, and thus check if system integration is successful in terms of real-time behavior. Additionally, the OEM can determine timing quality metrics for the integrated system, like, for instance, slack for future functionality, robustness to (slight) changes, etc. In case timing errors are detected or desired timing quality metrics are not satisfactory, the OEM can adjust the timing requirements for (a subset of) his suppliers, for instance by assigning smaller time budgets and go into another design iteration.

 

Figure 1 - OEM Side of the Exchange Models Use Case

 

Properties
Event Driven
Multiple Occurrences
Ongoing
Optional
PlannedYes
Repeatable