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
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
INFO Trigger::port : Port [0..*] A optional Port of through which the given effect is detected. Unified Modeling Language 2.5.1 Trigger::port, Trigger, Port
INFO InvocationAction::argument : InputPin [0..*] The InputPins that provide the argument values passed in the invocation request. Unified Modeling Language 2.5.1 InvocationAction, InvocationAction::argument
INFO InvocationAction::onPort : Port [0..1] For CallOperationActions, SendSignalActions, and SendObjectActions, an optional Port of the target object through which the invocation request is sent. Unified Modeling Language 2.5.1 InvocationAction, InvocationAction::onPort
INFO SendSignalAction::signal: The Signal whose instance is transmitted to the target. Unified Modeling Language 2.5.1 SendSignalAction::signal, SendSignalAction
INFO SendSignalAction::target: The InputPin that provides the target object to which the Signal instance is sent Unified Modeling Language 2.5.1 SendSignalAction::target, SendSignalAction, InputPin
INFO Instead of the client specifying which service it will use, the injector tells the client what service to use. The "injection" refers to the passing of a dependency (a service) into the object (a client) that would use it. Wikipedia software engineering, dependency injection
INFO In the typical "using" relationship the receiving object is called a client and the passed (that is, "injected") object is called a service. The code that passes the service to the client can be many kinds of things and is called the injector. Wikipedia software engineering, dependency injection
INFO In software engineering, dependency injection is a technique in which an object receives other objects that it depends on. These other objects are called dependencies. Wikipedia software engineering, dependency injection
INFO Trade studies are commonly used in the design of aerospace and automotive vehicles and the software selection process ... to find the configuration that best meets conflicting performance requirements. Wikipedia trade study, trade-off study
INFO These viable solutions are judged by their satisfaction of a series of measures or cost functions. These measures describe the desirable characteristics of a solution. They may be conflicting or even mutually exclusive. Wikipedia trade study, trade-off study
INFO A trade study or trade-off study, also known as a figure of merit analysis or a factor of merit analysis, is the activity of a multidisciplinary team to identify the most balanced technical solutions among a set of proposed viable solutions (FAA 2006). Wikipedia trade study, trade-off study
INFO Top: The formation of a virtual image using a diverging lens. Bottom: The formation of a virtual image using a convex mirror. In both diagrams, f is the focal point, O is the object and I is the image, shown in grey ... Wikipedia optics, focal point, virtual image, convex mirror
INFO Top: The formation of a real image using a convex lens. Bottom: The formation of a real image using a concave mirror. In both diagrams, f is the focal point, O is the object, and I is the image. Wikipedia real image, optics, convex lens, lens, focal point
INFO In an imperfect lens L, all the rays do not pass through a focal point. The smallest circle that they pass through C is called the circle of least confusion. Wikipedia optics, lens, circle of confusion, blur circle
INFO This is a major advantage for solar telescopes, where a field stop (Gregorian stop) can reduce the amount of heat reaching the secondary mirror and subsequent optical components. Wikipedia telescope, Gregorian reflector, field stop, optics, primary mirror, secondary mirror
INFO In the Gregorian design, the primary mirror creates a real image before the secondary mirror. This allows for a field stop to be placed at this location, so that the light from outside the field of view does not reach the secondary mirror. Wikipedia telescope, Gregorian reflector, field stop, optics, primary mirror, secondary mirror
INFO As the name implies, the "tube" of this design is actually composed of an upper 'cage assembly', which contains the secondary mirror, and focuser, held in place by several rigid poles over a ‘mirror box’ which contains the objective mirror. Wikipedia Dobsonian reflector, telescope, telescope tube, truss tube, Newtonian reflector, reflecting telescope
INFO Collapsible "truss tube" Dobsonians appeared in the amateur telescope making community as early as 1982 and allow the optical tube assembly, the largest component, to be broken down. Wikipedia Dobsonian reflector, telescope, telescope tube, truss tube, Newtonian reflector, reflecting telescope
INFO In optics, the f-number of an optical system such as a camera lens is the ratio of the system's focal length to the diameter of the entrance pupil ("clear aperture"). It is also known as the focal ratio, f-ratio, or f-stop Wikipedia optics, f-number, f-ratio, f-stop, focal length
INFO Light path in a Cassegrain telescope. Wikipedia Cassegrain telescope
INFO Light path in a Newtonian telescope. Wikipedia Newtonian reflector
INFO The overall focal ratio of the complete telescope will be f/8 and the optical prescription is an aplanatic Gregorian telescope. Wikipedia Gregorian reflector, aplanatic Gregorian reflector, optical telescope, telescope, reflecting telescope, reflector, Giant Magellan Telescope
INFO Diagram of the lightpath through a Gregorian telescope. Wikipedia Gregorian reflector, reflecting telescope, reflector, optical telescope
INFO In a prime focus design no secondary optics are used, the image is accessed at the focal point of the primary mirror. Wikipedia reflecting telescope, reflector, optical telescope, telescope, primary mirror, prime focus reflector
INFO The Gregorian telescope consists of two concave mirrors; the primary mirror (a concave paraboloid) collects the light and brings it to a focus before the secondary mirror (a concave ellipsoid) where it is reflected back through a hole in the centre ... Wikipedia Gregorian reflector, reflecting telescope, reflector, optical telescope, telescope, mirror, secondary mirror, primary mirror