Snippets (text quotes and extracts from authoritative sources)

A Snippet is a short quote or extract (typically a phrase, a sentence, or at most a few sentences) from an authoritative source document such as a specification, technical manual, or design manual. Throughout this site, content is often related to supporting Snippets and each Snippet page links back to the content pages that reference it! The Snippet and Note concepts are very closely related and they support each other.

The Snippet concept is also at the heart of the Parsing Analysis recipe for UML® and SysML®

Kind Snippet quote/extract Source UML keywords SysML keywords Keywords
INFO The output for SignalSource is named y and is typed by RealSignalOutElement, from the signal flow library ... SysPhS-1.1 SysPhS, signal processing
INFO Figure 49-Figure 50 show block definitions for components of TestBed and SignalProcessor in Figure 47 and Figure 48, respectively. SysPhS-1.1 Block SysPhS, signal processing, amplifier, filter, high-pass filter, low-pass filter
INFO Figure 47 shows an initial value for source amplitude amp, while Figure 48 shows initial values for amplifier signal gain g and filtering properties xi and alpha ... SysPhS-1.1 Property::defaultValue, Property initial values, context-specific values, initialValues compartment SysPhS, signal processing, amplifier, filter, high-pass filter, low-pass filter
INFO SysML initial values specify property values for components used in internal block diagrams. SysPhS-1.1 Property::defaultValue, Property initial values, context-specific values, initialValues compartment SysPhS, signal processing
INFO Figure 48 connects the signal processor input to an amplifier, the output of the amplifier to a high-pass filter in parallel with a low-pass filter, the outputs of the filters to a mixer, and the output of the mixer to the signal processor output. SysPhS-1.1 Port, Connector "standard" Port, SysML Internal Block Diagram SysPhS, signal processing
INFO Figure 47 connects a signal source to a signal processor, which it connects to a signal sink that displays the output. SysPhS-1.1 Port, Connector "standard" Port, SysML Internal Block Diagram SysPhS, signal processing
INFO Signals pass through ports in the direction shown by the arrows. Item flows on connectors indicate that the signals are real numbers. SysPhS-1.1 Port, Connector "standard" Port, FlowProperty, FlowProperty::direction, ItemFlow SysPhS, signal processing
INFO Part properties, typed by blocks ... represent the components of the system. They are connected through ports .. which represent signal outputs and inputs ... SysPhS-1.1 Port Block, part property, "standard" Port SysPhS, signal processing
INFO Figure 47 and Figure 48 show the internal structure of blocks TestBed and SignalProcessor, respectively SysPhS-1.1 SysML Internal Block Diagram SysPhS, signal processing
INFO A.3.2 System being modeled The signal processor and its testbed have a wave generator, an amplifier, high-pass and low-pass frequency filters, a mixer, and a signal sink, see Figure 46. SysPhS-1.1 SysPhS, signal processing, high-pass filter, low-pass filter, sine wave generator
INFO The source constraint defines the voltage across it as a sine wave with the parameter amp as its amplitude. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO The source constraint defines the circuit’s electrical source. The ground constraint specifies that the voltage at the ground pin is zero. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO The constraints for the resistor, capacitor, and inductor specify the voltage/current relationship with resistance, capacitance, and inductance, respectively. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO The sum of the current going through the two pins adds up to zero (one is the negative of the other), because the components do not create, destroy, or store charge. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO The current i through the component is equal to the current going through the positive pin. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO These specify that the voltage v across the component is equal to the difference between the voltage at the positive and negative pins. The current i through the component is equal to the current going through the positive pin. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO In this example, a constraint block BinaryElectricalComponentConstraint defines parameters and constraints common to resistors, inductors, capacitors, and sources, as shown in Figure 40. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO Equations define mathematical relationships between the values of numeric variables. Equations in SysML, are constraints in constraint blocks that use properties of the blocks (parameters) as variables. SysPhS-1.1 Constraint constraint parameter, ConstraintBlock, Block SysPhS
INFO A.2.2 System being modeled: The electrical circuit has six components: ground, electrical source, inductor, capacitor, and two resistors, see Figure 37. SysPhS-1.1 SysPhS
INFO The block SpringMassSys has a SysML constraint property smsc typed by SMSConstraint. The constraint block has six parameters, each bound to a property reachable from the spring mass system: SysPhS-1.1 ConstraintBlock SysPhS
INFO Figure 25 shows an example [USAGE OF A] constraint block for a signal flow application, using ports like those defined in Figure 22, Subclause 10.7.3, except in a system containing a spring attached to another object. SysPhS-1.1 ConstraintBlock SysPhS
CONSTRAINT PhSVariable: [5] changeCycle must be positive or 0. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language
CONSTRAINT PhSVariable: [4] changeCycle may be other than 0 only when isContinuous is false. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language
CONSTRAINT PhSVariable: [3] isConserved may be true only when isContinuous is true and the stereotyped property is on a block specialized from ConservedQuantityKind (see Subclause 11.2.2). SysPhS-1.1 SysPhS, SysML, Systems Modeling Language
CONSTRAINT PhSVariable: [2] isContinuous may be true only when the stereotyped property is typed by Real or one of its specializations. SysPhS-1.1 Real SysPhS, SysML, Systems Modeling Language
CONSTRAINT PhSVariable: [1] The stereotyped property must be typed by Real, Integer, or Boolean, or one of their specializations. SysPhS-1.1 Real, Integer, Boolean SysPhS, SysML, Systems Modeling Language
CONSTRAINT PhSConstant: [3] Properties stereotyped by PhSConstant must not redefine more than one other property, which must have the same name and type and must be stereotyped by PhSVariable or PhSConstant. SysPhS-1.1 Property::redefinedProperty SysPhS, SysML, Systems Modeling Language
CONSTRAINT PhSConstant: [2] Properties stereotyped by PhSConstant must have multiplicity 1, unless they are also stereotyped by MultidimensionalElement (see Subclause 11.5). SysPhS-1.1 SysPhS, SysML, Systems Modeling Language
CONSTRAINT PhSConstant: [1] Properties stereotyped by PhSConstant must be typed by Real, Integer, or Boolean, or one of their specializations. SysPhS-1.1 Real, Integer, Boolean SysPhS, SysML, Systems Modeling Language
INFO Continuous variables have values that are close to their values at nearby times in the past and future. Discrete variables have values that are the same as their values at nearby times in either the past or future, or both. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language
INFO A PhSVariable has values that can vary over time in a continuous or discrete fashion. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language
INFO A PhSConstant has values that do not change during simulation runs. Values can change between simulation runs. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language
INFO 11.5.2 Platform profile: This subclause defines stereotypes that Subclause 11.3 applies to the base classes and properties (including ports) of its blocks, to specify which library elements of Modelica and Simulink correspond to them. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language, Modelica, Simulink
INFO Component PhSConstants (SimulinkParameters and ModelicaParameters) for vectors and matrices have MultidimensionalElement applied, with dimension * and *,*, respectively ... SysPhS-1.1 Port "standard" Port
INFO Component input ports for vectors are typed by specializations of RealVectorSignalInElement, while component output ports for vectors are typed by specializations of RealVectorSignalOutElement ... SysPhS-1.1 Port "standard" Port
INFO Component input ports for scalars are typed by RealSignalInElement, IntegerSignalInElement, or BooleanSignalInElement, while component output ports for scalars are typed by RealSignalOutElement, IntegerSignalOutElement, or BooleanSignalOutElement ... SysPhS-1.1 Port "standard" Port
INFO Simulation platform data specified in the Component Ports (Input and Output), PhSConstants, and platform Parameters columns are scalar, unless marked with a V (vector) or an M (matrix). SysPhS-1.1 Port "standard" Port
INFO RealInSignalElement has an in flow property rsig, while RealOutSignalElement has the same property with an out direction. SysPhS-1.1 Port "standard" Port SysPhS
INFO Figure 22 shows an example signal flow application. The block Spring has two ports u and y, of type RealInSignalElement and RealOutSignalElement from the signal flow library ..., respectively. SysPhS-1.1 Port "standard" Port SysPhS
INFO When the computer is in StandBy, y.sigsp [ERROR] is set to 8, and when the computer is On, y.sigsp [ERROR] is set to 3. SysPhS-1.1 StateMachine, State, Transition, ChangeEvent, ChangeEvent::changeExpression SysPhS, SysML, Systems Modeling Language
INFO The transition from On to StandBy has a ChangeEvent with an expression indicating that the transition is triggered when u.sigsp [ERROR] is equal to 0. SysPhS-1.1 StateMachine, State, Transition, ChangeEvent, ChangeEvent::changeExpression SysPhS, SysML, Systems Modeling Language
INFO The transition from StandBy to On has a ChangeEvent with an expression indicating that the transition is triggered when u.sigsp [ERROR] is equal to 1 (this is a signal as in signal flow simulation, not as in SysML). SysPhS-1.1 StateMachine, State, Transition, ChangeEvent, ChangeEvent::changeExpression SysPhS, SysML, Systems Modeling Language
INFO The transition from the initial pseudostate to StandBy has a relative TimeEvent with an expression indicating that the transition fires 5 seconds after the initial pseudostate is entered. SysPhS-1.1 StateMachine, Pseudostate, PseudostateKind::initial, PseudostateKind, State, Transition, TimeEvent, TimeEvent::isRelative SysPhS, SysML, Systems Modeling Language
INFO The state machine has one initial pseudostate, and two states StandBy and On. SysPhS-1.1 StateMachine, Pseudostate, PseudostateKind::initial, PseudostateKind, State SysPhS, SysML, Systems Modeling Language
INFO Computer has ports u and y of type RealInSignalElement [ERROR:TYPO] and RealOutSignalElement [ERROR:TYPO] from the signal flow library (see Subclause 11.2.1), respectively. SysPhS-1.1 Port "standard" Port SysPhS, SysML, Systems Modeling Language
INFO The following Modelica code corresponds to Figure 29. SysPhS-1.1 Modelica, SysPhS
INFO The following Modelica code corresponds to Figure 28. It has a type Force, which extends Real, and the unit symbol N assigned to it. SysPhS-1.1 Modelica
INFO Modelica data types can be subtyped to add a unit symbol. The interpretation of this symbol is not defined in Modelica. SysPhS-1.1 Modelica
INFO Figure 28 shows how a value type with units is defined in SysML, from the units library in Figure 20 [ERROR], Subclause 11.2.2 [ERROR]. It has a value type Force that specializes the Real value type and has newton as unit. The newton unit has a symbol N. SysPhS-1.1 ValueType, Unit, ValueType::unit, Real SysPhS, SysML, Systems Modeling Language, ISO-80000
INFO SysML numeric value types can be linked to units, where units are modeled with the SysML Unit block. These units are linked to value types that are generalized by SysML’s numeric value types. Units and their symbols are from ISO 80000. SysPhS-1.1 DataType ValueType, Unit, ValueType::unit SysPhS, SysML, Systems Modeling Language, ISO-80000
INFO Data types in SysML are called value types. SysPhS-1.1 DataType ValueType SysPhS, SysML, Systems Modeling Language
INFO It has a model B with a val component. The val component has a start value of 10. A class A is defined with a component b of type B. A component modification indicates that the start value of b.val is 20.0. SysPhS-1.1 SysPhS, Modelica
INFO The following Modelica code corresponds to Figure 15 [ERROR]. SysPhS-1.1 SysPhS, Modelica
INFO SysML default and initial values correspond to start values of Modelica components. Start values are marked as fixed, requiring the values be set at the beginning of the simulation (otherwise, simulators only take the values as suggestions ...) SysPhS-1.1 Property::defaultValue initial values, context-specific values, value property SysPhS, Modelica
INFO f1 is replaced by p1.f, v1 is replaced by p1.lV, x is replaced by lengthchg, k is replaced by springcst, v is replaced by velocitydiff, f is replaced by forcethru, v2 is replaced by p2.v, and f2 is replaced by p2.f. SysPhS-1.1 Constraint ConstraintBlock, constraint parameter, constraint property SysPhS, SysML, Systems Modeling Language, Modelica
INFO The following Modelica code corresponds to Figure 26. It has five equations from the SysML constraint block. SysML parameter names are replaced in the Modelica equations according the bindings in Figure 14 [ERROR]: SysPhS-1.1 Constraint ConstraintBlock, constraint parameter, constraint property SysPhS, SysML, Systems Modeling Language, Modelica
INFO (and flow properties in SysML property paths leading to PhSVariables on conserved quantity kinds are omitted in Modelica, see Subclause 10.7.8). SysPhS-1.1 Constraint ConstraintBlock, constraint parameter, constraint property SysPhS, SysML, Systems Modeling Language, Modelica
INFO In a SysML block with constraint properties, the constraints correspond to the same equations in Modelica ... except the SysML parameters in those equations correspond in Modelica to the properties they are bound to in SysML SysPhS-1.1 Constraint ConstraintBlock, constraint parameter, constraint property SysPhS, SysML, Systems Modeling Language, Modelica
CONSTRAINT Block::6_valueproperties_composite: If a property owned by a SysML Block or SysML ValueType is typed by a SysML ValueType, then the aggregation attribute of the property shall be "composite." OMG Systems Modeling Language (SysML) 1.6
INFO SysML parameter names are replaced in the Modelica equations according to the bindings in Figure 13 [ERROR]: f is replaced by u, pos is replaced by y, x is replaced by position, k is replaced by springcst, v is replaced by velocity, m is replaced by mass. SysPhS-1.1 Constraint ConstraintBlock SysPhS, Modelica, SysML, Systems Modeling Language
INFO The following Modelica code corresponds to Figure 25. It has three equations from the constraint block. SysPhS-1.1 Constraint ConstraintBlock SysPhS, Modelica, SysML, Systems Modeling Language
INFO In a SysML block with constraint properties, the constraints correspond to the same equations in Modelica ... except the SysML parameters in those constraints correspond in Modelica to the properties they are bound to in SysML. SysPhS-1.1 Constraint ConstraintBlock, constraint parameter, BindingConnector SysPhS, Modelica, SysML, Systems Modeling Language
INFO Model [ERROR] contains a connect equation linking component p2 of s1 to component p1 of s2. SysPhS-1.1 Connector, Port "standard" Port, FlowProperty
INFO The following Modelica code corresponds to Figure 24. It has a model Example with two components s1 and s2 of types SpringA and SpringB, respectively. The models SpringA and SpringB have two components p1 and p2 of type Flange, defined similarly to Spring SysPhS-1.1 Connector, Port "standard" Port, FlowProperty
INFO SysML connectors correspond to Modelica connect equations, which link components typed by Modelica connectors. This depends on the correspondence between SysML port types and Modelica connectors ... SysPhS-1.1 Connector, Port "standard" Port, FlowProperty
INFO The following Modelica code corresponds to Figure 21. It has a model A, with three properties v1, v2 and v3 of type Real, that are continuous, discrete, and parameter, respectively. SysPhS-1.1 SysPhS
INFO SysML packages correspond to Modelica models defined as the root element of a file. The following Modelica code corresponds to Figure 17. It has a model P owning a model B ... SysPhS-1.1 SysPhS
INFO The following Modelica code corresponds to Figure 20. It has a model A with component c1 indicated as replaceable, and a model B extending A with a component of the same name redeclaring it to alter the type ... SysPhS-1.1 SysPhS
INFO The following Modelica code corresponds to Figure 19. It has a model A with a component c1 of type C, and a model B that extends A. As a result, B inherits the component c1 from A. SysPhS-1.1 SysPhS
INFO The following Modelica example corresponds to the SysML block A in Figure 18. It has a Modelica model A corresponding to the SysML block A, with a component b1 typed by Modelica model B, corresponding to the SysML property b1 typed by block B. SysPhS-1.1 SysPhS
INFO The flange of the mass and the flange of the ground replace the participant properties of the association block and are connected to the property f of type Friction in the same way as in the association block SysPhS-1.1 Connector AssociationBlock, ConnectorProperty SysPhS, SysML, Systems Modeling Language
INFO The connector and its property fa in Figure 2 is replaced by the content of the association block FrictionAssociation (the connector and its property and association block are removed). SysPhS-1.1 Connector AssociationBlock, ConnectorProperty SysPhS, SysML, Systems Modeling Language
INFO Connectors typed by association blocks, including their connector properties, are replaced by the internal structure of the association blocks. Figure 3 shows the content of Figure 2 after processing. SysPhS-1.1 Connector AssociationBlock, ConnectorProperty SysPhS, SysML, Systems Modeling Language
INFO The following Modelica code corresponds to Figure 23. It has a model Spring, with two components p1 and p2 of type Flange. Flange is a connector that has one flow component f, and one regular component lV. SysPhS-1.1 SysPhS
INFO The following Modelica code corresponds to Figure 22. It has a model Spring, with two components u and y of type Real and of direction respectively in and out. SysPhS-1.1 SysPhS
INFO By default, Modelica properties are continuous. PhSVariables with isContinuous=true correspond to continuous components, PhSVariables with isContinuous=false correspond to discrete components, and PhSConstants correspond to parameter variables. SysPhS-1.1 Modelica, SysPhS, SysML, Systems Modeling Language
INFO 10.6.3 Modelica modeling: The variability of Modelica properties are of four kinds: continuous, discrete, parameter, and constant. SysPhS-1.1 Modelica, SysPhS, SysML, Systems Modeling Language
INFO SysPhS-1.1: This specification: Gives translations between SysML as extended above and two widely-used simulation languages and tools for physical interaction and signal flow simulation. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language, execution, simulation, physical interaction
INFO SysPhS-1.1: This specification: Includes a platform-independent SysML library of simulation elements that can be reused in system models. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language, execution, simulation, physical interaction
INFO SysPhS-1.1: This specification: Provides a human-usable textual syntax for mathematical expressions. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language, execution, simulation, physical interaction
INFO SysPhS-1.1: This specification: Extends SysML with additional information needed to model physical interaction and signal flow simulation independently of simulation platforms. SysPhS-1.1 SysPhS, SysML, Systems Modeling Language, execution, simulation, physical interaction
INFO Today this process can occur in reverse, with the digital model developed first followed by the physical asset. ANZLIC 2019 - Principles for Spatially Enabled Digital Twins of the Built and Natural Environment in Australia digital twin
INFO Traditionally, industry has created digital twins by retrospectively mapping, scanning, surveying, digitising or developing a digital copy of a real world object. ANZLIC 2019 - Principles for Spatially Enabled Digital Twins of the Built and Natural Environment in Australia digital twin
INFO Sensors [DISPUTED] in office buildings for example, can adjust lights, blinds and temperature to balance optimal working environment with energy consumption, with the digital twin managing and adjusting in near real-time. ANZLIC 2019 - Principles for Spatially Enabled Digital Twins of the Built and Natural Environment in Australia
INFO The famous pipe. How people reproached me for it! And yet, could you stuff my pipe? No, it's just a representation, is it not? So if I had written on my picture "This is a pipe", I'd have been lying! Wikipedia
INFO Often depicting ordinary objects in an unusual context, his work is known for challenging observers' preconditioned perceptions of reality. Wikipedia
INFO René François Ghislain Magritte was a Belgian surrealist artist. He became well known for creating a number of witty and thought-provoking images. Wikipedia
INFO An actuator is a device that is responsible for moving or controlling a mechanism or system. It is controlled by a signal from a control system or manual control. Wikipedia sensor, control system
INFO A sensor is a transducer that receives and responds to a signal or stimulus from a physical system. It produces a signal, which represents information about the system Wikipedia sensor, control system
INFO In contrast to traditional digital models, digital twins can connect with the physical ‘twin’ they model, changing alongside the physical system via real-time sensors and actuators. ANZLIC 2019 - Principles for Spatially Enabled Digital Twins of the Built and Natural Environment in Australia digital twin, Digital Twin Instance, sensor, actuator, control loop, ANZLIC-2019
INFO They encompass potential or actual physical assets, processes, people, places, systems, devices and the natural environment. ANZLIC 2019 - Principles for Spatially Enabled Digital Twins of the Built and Natural Environment in Australia
INFO Digital twins are dynamic, data driven, multi-dimensional digital replicas of a physical entity. ANZLIC 2019 - Principles for Spatially Enabled Digital Twins of the Built and Natural Environment in Australia
CONSTRAINT BoundReference::7_cannot_redefine_boundreference BoundReferences shall not be applied to properties that are related by redefinition to other properties with BoundReference applied. OMG Systems Modeling Language (SysML) 1.6 BoundReference Systems Modeling Language, SysML
CONSTRAINT Block:8_specializations_are_blocks: Any classifier that specializes a Block shall also have the Block stereotype or one of its specializations applied. OMG Systems Modeling Language (SysML) 1.6 Stereotype Block Systems Modeling Language, SysML
INFO Validation can be expressed by the query "Are you building the right thing?" and verification by "Are you building it right?" Wikipedia validation, verification, V&V, V-model, ISO/IEC/IEEE 15288, ISO/IEC/IEEE 15288-2015, ISO/IEC/IEEE 12207:2017, ISO/IEC/IEEE 12207
INFO Completion events have dispatching priority. That is, they are dispatched ahead of any pending Event occurrences in the event pool. Unified Modeling Language 2.5.1 StateMachine, State, completion, completion transition, implicit trigger, Transition, Trigger, completion event, Trigger::event, State::entry, State::doActivity
INFO In case of simple States, a completion event is generated when the associated entry and doActivity Behaviors have completed executing. If no such Behaviors are defined, the completion event is generated upon entry into the State. Unified Modeling Language 2.5.1 StateMachine, State, completion, completion transition, implicit trigger, Transition, Trigger, completion event, Trigger::event, State::entry, State::doActivity
INFO The event that enables this trigger is called a completion event and it signifies that all Behaviors associated with the source State of the completion Transition have completed execution. Unified Modeling Language 2.5.1 StateMachine, State, completion, completion transition, implicit trigger, Transition, Trigger, completion event, Trigger::event
INFO 14.2.3.8.3 Completion Transitions and completion events: A special kind of Transition is a completion Transition, which has an implicit trigger. Unified Modeling Language 2.5.1 StateMachine, State, completion, completion transition, implicit trigger, Transition, Trigger
INFO Trigger::event : Event [1..1] The Event that detected by the Trigger. Unified Modeling Language 2.5.1 Trigger, Trigger::event