The Verify relationship is shown on Figure 16-7 using callout notation anchored to the diagram frame, which indicates that the BurnishTest test case verifies the Burnish requirement. Source OMG Systems Modeling Language (SysML) 1.6
Figure 17-1 [Figure 16-7] is a state machine diagram of the BurnishTest test case, which expresses the textual sequence and criteria of the Burnish requirement in state machine form. Source OMG Systems Modeling Language (SysML) 1.6
The Burnish requirement is shown as having a Verify relationship to the BurnishTest test case using callout notation on the diagram, indicating that the Burnish requirement is verified by the BurnishTest test case. Source OMG Systems Modeling Language (SysML) 1.6
The example in Figure 16-6 is taken from the automotive safety domain, and shows a Burnish requirement contained in the NHTSASafetyRequirements requirement. Note that the text of the Burnish requirement indicates a specific sequence of steps and transitio Source OMG Systems Modeling Language (SysML) 1.6
Figure 16-5 illustrates the use of the Copy dependency to allow a single requirement to be reused in several requirements hierarchies. The master tag provides a textual reference to the reused requirement. Source OMG Systems Modeling Language (SysML) 1.6
The diagram in Figure 16-3 shows derived requirements and refers to the design elements that satisfy them. The rationale is also shown as a basis for the design solution. Source OMG Systems Modeling Language (SysML) 1.6
The diagram in Figure 16-2 shows an example of a compound requirement decomposed into multiple subrequirements. Source OMG Systems Modeling Language (SysML) 1.6
The allocation table can also be shown using a sparse matrix style as in the following example shown in Figure 15-9. Source OMG Systems Modeling Language (SysML) 1.6
The table shown in Figure D.40 is provided as a specific example of how the «allocate» dependency may be depicted in tabular form, consistent with the automotive example above. Source OMG Systems Modeling Language (SysML) 1.6
The need also arises, when adding detail to a structural model, to allocate a connector (at a more abstract level) to a part (at a more concrete level). Source OMG Systems Modeling Language (SysML) 1.6
For example, if a particular user model includes an abstract logical structure, it may be important to show how these model elements are allocated to a more concrete physical structure. Source OMG Systems Modeling Language (SysML) 1.6
Systems engineers have frequent need to allocate structural model elements (e.g., blocks, parts, or connectors) to other structural elements. Source OMG Systems Modeling Language (SysML) 1.6
Allocation of ControlFlow is not shown as an example, but it is not prohibited in SysML. Source OMG Systems Modeling Language (SysML) 1.6
Figure 15-5 shows flow allocation of [an] ObjectFlow to a Connector, or alternatively to an ItemFlow. Source OMG Systems Modeling Language (SysML) 1.6
The allocation to Activity6 comes from a nested part, and uses the attributes of DirectedRelationshipPropertyPath to specify the path of properties to reach that part. The sourceContext of the allocation is Block4 and the sourcePropertyPath is (Part5). Source OMG Systems Modeling Language (SysML) 1.6
Note that the AllocateActivityPartition, if used in this manner, is unambiguously associated with behavior allocation. Source OMG Systems Modeling Language (SysML) 1.6
Specific behavior allocation of Actions to Parts are depicted in Figure 15-4. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.10 shows the sequence of communication that occurs inside the HybridSUV when the vehicle is started successfully. Source OMG Systems Modeling Language (SysML) 1.6
The “hybridSUV” lifeline represents another interaction which further elaborates what happens inside the “hybridSUV” when the vehicle is started. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.9 shows an interaction that includes events and messages communicated between the driver and vehicle during the starting of the vehicle. Source OMG Systems Modeling Language (SysML) 1.6
CombinedFragments are used to illustrate that steering can take place at the same time as controlling the speed and that controlling speed can be either idling, accelerating/cruising, or braking. Source OMG Systems Modeling Language (SysML) 1.6
To manage the complexity, a hierarchical sequence diagram is used which refers to other interactions that further elaborate the system behavior (“ref StartVehicleBlackBox”). Source OMG Systems Modeling Language (SysML) 1.6
Figure D.7 illustrates the overall system behavior for operating the vehicle in Sequence diagram format. Source OMG Systems Modeling Language (SysML) 1.6
Interactions in block definition diagrams can also appear with the same notation as InteractionUses. Source OMG Systems Modeling Language (SysML) 1.6
Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is a parameter of the interaction, can be used as the end of the associations towards the parameter type. Source OMG Systems Modeling Language (SysML) 1.6
Properties with AdjunctProperty applied, where the principal of the AdjunctProperty is an interaction use, can be used as the end of the associations towards the interaction being used. Source OMG Systems Modeling Language (SysML) 1.6
Interactions in block definition diagrams appear as regular blocks, except the «interaction» keyword may be used to indicate the Block stereotype is applied to an interaction, as shown in Figure 12-1 Source OMG Systems Modeling Language (SysML) 1.6
In an instance of Operating Car, which is one execution of it, instances of Brake Pressure and Modulation Frequency are linked to the execution instance when they are in the object nodes of the activity. Source OMG Systems Modeling Language (SysML) 1.6
Figure 11-14 shows a block definition diagram with composition associations between the activity in Figure 11-10 and the types the object nodes in that activity, with AdjunctProperty applied to the object node type end. Source OMG Systems Modeling Language (SysML) 1.6
Like all composition, if an instance of Operating Car is destroyed, terminating the execution, the executions it owns are also terminated. Source OMG Systems Modeling Language (SysML) 1.6
Each instance of Operating Car is an execution of that behavior. It owns the executions of the behaviors it invokes synchronously, such as Driving. Source OMG Systems Modeling Language (SysML) 1.6
Figure 11-13 shows a block definition diagram with composition associations between the activities and AdjunctProperty applied to the part ends in Figures 11.10, 11.11, and 11.12, as an alternative way to show the activity decomposition of Figures ... Source OMG Systems Modeling Language (SysML) 1.6
The edges coming out of the decision node indicate the probability of each branch being taken. Source OMG Systems Modeling Language (SysML) 1.6
The decision node and guards determine if the brake pressure is greater than zero, and flow is directed to value specification actions that output an enabling or disabling control value from the activity. Source OMG Systems Modeling Language (SysML) 1.6
The activity diagram for the control operator Enable on Brake Pressure > 0 is shown in Figure 11-12. Source OMG Systems Modeling Language (SysML) 1.6
The result of Calculate Traction is filtered by a decision node for a threshold value and Calculate Modulation Frequency determines the output of the activity. Source OMG Systems Modeling Language (SysML) 1.6
A traction index is calculated every 10 ms, which is the slower of the two signal rates. The accelerometer signals come in continuously, which means the input to Calculate Traction does not buffer values. Source OMG Systems Modeling Language (SysML) 1.6
When Monitor Traction is enabled, it begins listening for signals coming in from the wheel and accelerometer, as indicated by the signal receipt symbols on the left, which begin listening automatically when the activity is enabled. Source OMG Systems Modeling Language (SysML) 1.6
The activity diagram for Monitor Traction is shown in Figure 11-11. Source OMG Systems Modeling Language (SysML) 1.6
The lower connector shows its connector property explicitly, enabling the pipe it contains to be connected to a mounting bracket (the additional part and connector definitions are omitted for brevity). Source OMG Systems Modeling Language (SysML) 1.6
Figure 9-14 modifies Figure 9-9 to use Plumbing as a connector type within the Water Delivery association block. Source OMG Systems Modeling Language (SysML) 1.6
Figure 9-13 shows the internal structure for the Plumbing association block, which includes a pipe and two fittings (the additional part and connector definitions are omitted for brevity). Source OMG Systems Modeling Language (SysML) 1.6
Figure 9-12 adds a Plumbing association block for the association between Spigot and Faucet Inlet in Figure 9-11. Source OMG Systems Modeling Language (SysML) 1.6
The composite connector for Water Delivery is reused three times to establish connections between spigots on the water supply and the inlets of faucets on the bath, sink, and shower. Source OMG Systems Modeling Language (SysML) 1.6
The top portion of Figure 9-11 shows specializations of the block WaterClient into Bath, Sink, and Shower. These are used as part types in the internal structure of the block House 2 shown in the lower portion of the figure Source OMG Systems Modeling Language (SysML) 1.6
The connector in the top view “decomposes” into the subconnectors in the lower view according to the internal structure of Water Delivery. The subconnectors relate the nested ports of :WaterSupply to the nested ports of :WaterClient. Source OMG Systems Modeling Language (SysML) 1.6
Figure 9-10 shows two views of a block House with a connector of type Water Delivery. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.40 shows the same allocation relationships shown in Figure D.38, but in a more compact tabular representation. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.41[ ]shows a particular Hybrid SUV (VIN number) satisfying the EPA fuel economy test. Serial numbers of specific relevant parts are indicated. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.39 depicts a subset of the PowerSubsystem, specifically showing the allocation relationships generated in Figure D.38. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.37 defines a decomposition of the activities and objectFlows from the activity diagram in Figure D.36. Source OMG Systems Modeling Language (SysML) 1.6
The stereotypes on the object nodes between actions in the figure apply to parameters of the behaviors or operations called by the actions (see the notation for object nodes described in 11.3.1.4, ObjectNode, Variables, and Parameters). Source OMG Systems Modeling Language (SysML) 1.6
It is the intent of the systems engineer in this example to allocate this behavior to parts of the PowerSubsystem. It is quickly found, however, that the behavior as depicted cannot be allocated, and must be further decomposed. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.36 shows the top level behavior of an activity representing acceleration of the HSUV. Source OMG Systems Modeling Language (SysML) 1.6
It assumes a constant 100hp at the drive wheels, 4000lb gross vehicle weight, and constant values for Cd and Cf. Source OMG Systems Modeling Language (SysML) 1.6
For illustration purposes, however, the interaction shown in Figure D.35 was generated based on the constraints and parameters of the StraightLineVehicleDynamics constraintBlock, as described in the Figure D.33. Source OMG Systems Modeling Language (SysML) 1.6
The constraints and parameters in Figure D.33 are detailed in Figure D.34 in Block Definition Diagram format. Note the use of valueTypes [ValueTypes] originally defined in Figure D.2. Source OMG Systems Modeling Language (SysML) 1.6
The StraightLineVehicleDynamics constraint block from Figure D.32 has been expanded in Figure D.33. ConstraintNotes are used, which identify each constraint using curly brackets {}. In addition, Rationale has been used to explain the meaning ... Source OMG Systems Modeling Language (SysML) 1.6
Since overall fuel economy is a key requirement on the HSUV design, this example applies significant detail in assessing it. Figure D.32 shows the constraint blocks and properties necessary to evaluate fuel economy. Source OMG Systems Modeling Language (SysML) 1.6
This non-normative extension includes stereotypes for an objective function and a measure of effectiveness. The objective function is a stereotype of a ConstraintBlock and the measure of effectiveness is a stereotype of a block property. Source OMG Systems Modeling Language (SysML) 1.6
It will also be assumed that the overall mission cost effectiveness can be determined by applying an objective function to a set of criteria, each of which is represented by a measure of effectiveness. Source OMG Systems Modeling Language (SysML) 1.6
A measure of effectiveness (moe) represents a parameter whose value is critical for achieving the desired mission cost effectiveness. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.30 shows the Requirements and VnV views and the supporting views that complete the description of Requirements and VnV respectively for the Hybrid SUV. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.29 shows the Requirements and VnV views and the model elements they expose. Note that the expose relationship relies on the viewpoint method to identify the entire set of elements that appear in the view. Source OMG Systems Modeling Language (SysML) 1.6
The Fuel store represents a quantity of fuel in the FuelTankAssy, which is drawn by the FuelPump for use in the engine, and is refreshed, to some degree, by fuel returning to the FuelTankAssy via the FuelReturnLine. Source OMG Systems Modeling Language (SysML) 1.6
The fdist connector inside the InternalCombustionEngine block has been expanded into the fuel regulator and fuel rail parts. These more detailed design elements are related to the original connectors using the allocation relationship. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.25 shows how the connectors fuelDelivery and fdist on Figure D.19 have been expanded to include design detail. The fuelDelivery connector is actually two connectors, one carrying fuelSupply and the other carrying fuelReturn. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.24 is a parametric diagram showing how fuel flowrate is related to FuelDemand and FuelPressure value properties. Source OMG Systems Modeling Language (SysML) 1.6
The ports on the FuelTankAssembly and InternalCombustionEngine (as shown in Figure D.19) are defined in Figure D.23. Source OMG Systems Modeling Language (SysML) 1.6
Inversely, the InternalCombustionEngine can read the isControlOn property of the PowerControlUnit across the connector to determine if the unit is still operating, and possibly shut down if it is not. Source OMG Systems Modeling Language (SysML) 1.6
By invoking these operations, the PowerControlUnit can set the throttle and mixture of the InternalCombustionEngine. The PowerControlUnit can also read properties of the InternalCombustionEngine across the connector to find out the rpm, temperature, ... Source OMG Systems Modeling Language (SysML) 1.6
Since the ecu:PowerControlUnit part and ice:InternalCombustionEngine part are connected via these ports, the ecu:PowerControlUnit part may invoke setThrottle and setMixture on the ice:InternalCombustionEngine part via its ice port, across the connector... Source OMG Systems Modeling Language (SysML) 1.6
This means the provided features of ICE are provided by the ctrl port of InternalCombustionEngine, and required by the ice port of PowerControlUnit, while the required features of ICE are required by the ctrl port of InternalCombustionEngine, and provided Source OMG Systems Modeling Language (SysML) 1.6
For example, the ICE block specifies the provided operations setMixture and setThrottle, the provided properties RPM, temperature, and isKnocking, and required property isControlOn, as shown in Figure D.20. This block types the ctrl port of ... Source OMG Systems Modeling Language (SysML) 1.6
The ecu:PowerControlUnit part has three ports with required and provided features, each connected to a port of another part. Each of the ports in this example is typed by a block specifying provided and required features available via connectors ... Source OMG Systems Modeling Language (SysML) 1.6
Figure 9-6 is a fragment of the ibd:PwrSys diagram used in the HybridSUV Sample Problem in Annex D. (The complete diagram is in Figure D.19.) Source OMG Systems Modeling Language (SysML) 1.6
These multiplicities may be assumed if not shown on a diagram. To avoid confusion, any multiplicity other than the default should always be shown on a diagram. Source OMG Systems Modeling Language (SysML) 1.7beta1
A part or shared association has a default multiplicity of [0..1] on the black or white diamond end. A unidirectional association has a default multiplicity of 1 on its target end. Source OMG Systems Modeling Language (SysML) 1.7beta1
SysML defines defaults for multiplicities on the ends of specific types of associations. Source OMG Systems Modeling Language (SysML) 1.7beta1
The dashed borders on Fuel denote a store, which keeps track of the amount and mass of fuel in the FuelTankAssy. This is also depicted in Figure D.18. Source OMG Systems Modeling Language (SysML) 1.6
The dashed borders on FrontWheel and BrakePedal denote the “use-not-composition” relationship depicted elsewhere in Figure D.16 and Figure D.18. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.19 shows how the parts of the PowerSubsystem block, as defined in the diagram above, are used. It shows connectors between parts, ports, and connectors with item flows. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.17 shows how the top level model elements in the above diagram are connected together in the HybridSUV block. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.16 defines components of the HybridSUV block. Note that the BrakePedal and WheelHubAssembly are used by, but not contained in, the PowerSubsystem block. Source OMG Systems Modeling Language (SysML) 1.6
Note that the interactions DriveBlackBox and Stac4rtVehicleBlackBox (described in D.4.3 Elaborating Behavior (Sequence and State Machine Diagrams), are depicted as owned by the AutomotiveDomain block. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.15 provides definition for the concepts previously shown in the context diagram. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.14 contains two diagrams that show requirement containment (decomposition), and requirements derivation in tabular form. This is a more compact representation than the requirements diagrams shown previously. Source OMG Systems Modeling Language (SysML) 1.6
The Power requirement is satisfied by the PowerSubsystem, and a Max Acceleration test case verifies the Acceleration requirement. Source OMG Systems Modeling Language (SysML) 1.6
The “refine” relation, introduced in Figure D.12, shows how the Acceleration requirement is refined by a similarly named use case. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.13 focuses on the Acceleration requirement, and relates it to other requirements and model elements. Source OMG Systems Modeling Language (SysML) 1.6
Note also that rationale can be attached to the «deriveReqt» relationship. In this case, rationale is provided by a referenced document “Hybrid Design Guidance.” Source OMG Systems Modeling Language (SysML) 1.6
Note how PowerSourceManagement is “RefinedBy” the HSUVOperationalStates model (Figure D.8). Source OMG Systems Modeling Language (SysML) 1.6
Various other model elements may be necessary to help develop a derived requirement, and these model element may be related by a «refinedBy» relationship. Source OMG Systems Modeling Language (SysML) 1.6
Derived requirements, for the purpose of this example, express the concepts of requirements in the HSUVSpecification in a manner that specifically relates them to the HSUV system. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.12 shows a set of requirements derived from the lowest tier requirements in the HSUV specification. Source OMG Systems Modeling Language (SysML) 1.6
The containment (cross hair) relationship, for purposes of this example, refers to the practice of decomposing a complex requirement into simpler, single requirements. Source OMG Systems Modeling Language (SysML) 1.6
The vehicle system specification contains many text based requirements. A few requirements are highlighted in Figure D.11, including the requirement for the vehicle to pass emissions standards, which is expanded for illustration purposes. Source OMG Systems Modeling Language (SysML) 1.6
The lifelines on Figure D.10 (“whitebox” sequence diagram) need to come from the Power System decomposition. This now begins to consider parts contained in the HybridSUV block. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.9 shows a “black box” interaction, but references “StartVehicleWhiteBox” (Figure D.10), which will decompose the lifelines within the context of the HybridSUV block. Source OMG Systems Modeling Language (SysML) 1.6
This diagram expresses only the nominal states. Exception states, like “acceleratorFailure,” are not expressed on this diagram. Source OMG Systems Modeling Language (SysML) 1.6
Also note that this state machine refines the requirement “PowerSourceManagment,” which will be elaborated in the requirements sub clause of this sample problem. Source OMG Systems Modeling Language (SysML) 1.6
Note that this state machine was developed in conjunction with the DriveBlackBox interaction in Figure D.7. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.8 depicts the operational states of the HSUV block, via a State Machine named “HSUVOperationalStates.” Source OMG Systems Modeling Language (SysML) 1.6
The conditions for each alternative in the alt controlSpeed sub clause are expressed in OCL, and relate to the states of the HybridSUV block, as shown in Figure D.8. Source OMG Systems Modeling Language (SysML) 1.6
“BlackBox” for the purpose of this example, refers to how the subject system (HybridSUV block) interacts only with outside elements, without revealing any interior detail. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.7 shows the interactions between driver and vehicle that are necessary for the “Drive the Vehicle” Use Case. This diagram represents the “DriveBlackBox” interaction, with [which] is owned by the AutomotiveDomain block. Source OMG Systems Modeling Language (SysML) 1.6
Maintenance, registration, and insurance of the vehicle would be covered under a separate set of goal-oriented use cases. Source OMG Systems Modeling Language (SysML) 1.6
Goal-level Use Cases associated with “Operate the Vehicle” are depicted in the following diagram. These use cases help flesh out the specific kind of goals associated with driving and parking the vehicle. Source OMG Systems Modeling Language (SysML) 1.6
The use case diagram for “Drive Vehicle” in Figure D.5 depicts the drive vehicle usage of the vehicle system. The subject (HybridSUV) and the actors (Driver, Registered Owner, Maintainer, Insurance Company, DMV) interact to realize the use case. Source OMG Systems Modeling Language (SysML) 1.6
Note how the relationships in this diagram are also reflected in the Automotive Domain Model Block Definition Diagram, Figure D.15. Source OMG Systems Modeling Language (SysML) 1.6
The associations among the classes may represent abstract conceptual relationships among the entities, which would be refined in subsequent diagrams. Source OMG Systems Modeling Language (SysML) 1.6
Also, a background such as a map can be included to provide additional context. Source OMG Systems Modeling Language (SysML) 1.6
The spatial relationship of the entities on the diagram sometimes conveys understanding as well, although this is not specifically captured in the semantics. Source OMG Systems Modeling Language (SysML) 1.6
Each model element depicted may include a graphical icon to help convey its intended meaning. Source OMG Systems Modeling Language (SysML) 1.6
The «system» and «external» stereotypes are user defined, not specified in SysML, but help the modeler to identify the system of interest relative to its environment. Source OMG Systems Modeling Language (SysML) 1.6
The entities are conceptual in nature during the initial phase of development, but will be refined as part of the development process. Source OMG Systems Modeling Language (SysML) 1.6
The diagram usage enables the modeler or methodologist to specify a unique usage of a SysML diagram type using the extension mechanism described in Annex A, “Diagrams.” Source OMG Systems Modeling Language (SysML) 1.6
The term “context diagram,” in Figure D.4, refers to a user-defined usage of an internal block diagram, which depicts some of the top level entities in the overall enterprise and their relationships. Source OMG Systems Modeling Language (SysML) 1.6
Note that the «view» models contain no model elements of their own, and that changes to the model in other packages are automatically updated in the Operational and Performance Views. Source OMG Systems Modeling Language (SysML) 1.6
The relationship between the views (OperationalView and PerformanceView) and the rest of the user model are explicitly expressed using the «import» relationship. Source OMG Systems Modeling Language (SysML) 1.6
Model elements are contained in packages, and relationships between packages (or specific model elements) are shown on this diagram. Source OMG Systems Modeling Language (SysML) 1.6
The package diagram (Figure D.3) shows the structure of the model used to evaluate the sample problem. Source OMG Systems Modeling Language (SysML) 1.6
More specific value types can define the concrete data representations that a digital computer can process, such as conventional Float, Integer, or String types. Source OMG Systems Modeling Language (SysML) 1.6
For example, the SysML "Real" ValueType expresses the mathematical concept of a real number, but does not impose any restrictions on the precision or scale of a fixed or floating-point representation that expresses this concept. Source OMG Systems Modeling Language (SysML) 1.6
The explicit structural allocation between the original connectors of Figure D.19 and this new bus architecture is shown in Figure D.39. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.22 continues the refinement of this Controller Area Network (CAN) bus architecture using ports. Source OMG Systems Modeling Language (SysML) 1.6
Figure D.21 is an incomplete first step in the refinement of this bus architecture, as it begins to specify the flow properties for InternalCombustionEngine, the Transmission, and the ElectricalPowerController. Source OMG Systems Modeling Language (SysML) 1.6
For purposes of example, the ports, flows, and related point-to-point connectors in Figure D.19 are being refined into a common bus architecture. For this example, ports with flow properties have been used to model the bus architecture. Source OMG Systems Modeling Language (SysML) 1.6
This single signal carries the temperature, rpm, and knockSensor information of the engine. Source OMG Systems Modeling Language (SysML) 1.6
For example, a junction Pseudostate can be used to merge multiple incoming Transitions into a single outgoing Transition representing a shared continuation path. Source Unified Modeling Language 2.5.1
