The simulation system uses a number of conventions to help standardise and clarify concepts.

Algorithm conventions are used for the highly-detailed design and documentation of the simulator's inner workings. 

Operation conventions are used for more 'real-world' descriptions of the operating principles of the simulator's systems.

Algorithm Conventions

These conventions are used in the creation and documentation of simulation algorithms.

Systems

A simulation system represents a physical machine or device that performs a particular function, for example a Toroidal Field Generator creates a magnetic containment field. A system is typically made up of a number of components.

Components

A component is a discrete part of a system that receives one or more variables as inputs, calculates a result using one or more functions, and outputs a variable. That variable may then be modified before being passed on to another component.

Standard components are visible to the crew: They appear on schematics, their output value and status may be displayed on a console and their behviour described in technical documentation (although not usually to the extent of publishing the component's underlying mathematical function). 

Other components interact with the simulation environment in different ways depending on their type:

Control Components

These components receive and manage control inputs from the crew (for example setting power levels).

System Components

These components represent the 'inherent properties' of a system and are transparent to crew: Their output value or status is never displayed on a console and their underlying functions are never published. The impact of system components is only every observed empirically by monitoring the response of the simulation system as a whole.

Production Components

These components are used by mission operations (or programmatically within the algorithm) to simulate engineering events (see below). For example, a system may include a production component that simulates the effect of a coolant leak and impacts the system's behaviour accordingly. Like system components, production components are invisible to the crew.

Functions

Functions describe how a combination of variables are calculated to arrive at a particular result, for example how much a component will output given the amount of power applied. For the purposes of the simulation that result is itself a variable, typically passed onto another component or system in the simulation.

Response Profiles

Functions are also useful to describe the behaviour of a component over a range of inputs - this is known as the component's response profile. The reponse profile can be visually presented as a graph.

Modifiers

A modifier is function that alters the output of a component in order to ensure compatibility with the rest of the system. For example, the output of a component might be in the range 0-10 units, but the component receiving that output requires a range of 0-1000 for successful completion of its own calculations.

Variables

Variables are the building blocks of the simulator. A variable is a numerical value that represents a specific measurement or input, which is identified with a descriptive name and an abbreviation. A variable can be the result of a user input (for example, the amount of power a user chooses to apply to a specific power input), a fixed system variable (representing a system 'constant') or the output of a function (see below).

Standard Variables

Standard variables also include definitions of the variable's nominal (target) value and range, including the variable's certified operating range (upper and lower) and maximum/minimum range.

Simple Variables

Simple variables only have a numerical value, without any range definition.

Discrete Variables

A variable may appear on an algorithm schematic as an input variable to a component or as a discrete part of the algorithm similar to a component. Discrete variables are typically used where their inclusion in a system does not require a component to calculate them - effectively, they behave as 'simple' components.

Discrete variables are represented in algorithm schematics as circles to differentiate themselves from components. 

Like components, discrete variables may have particular types:

Control variables: These variables may be altered by the crew (for example setting power levels), with the selected value passed directly on to a downstream component.

System variables: These variables are transparent to crew: Their value never displayed on a console or published. 

Production variables: These variables may be altered by mission operations (or programmatically within the algorithm) to simulate an engineering event by altering the behaviour of a system. Like system variables, production variables are invisible to the crew.

Simulation Operation Conventions

These conventions are used when describing a simulation system in its operating environment. This mode of description is at a more generalised, 'real-world' level (such as you might see in a tech database article for example) than that defining simulation algorithms.

Operating Factors

An operating factor is an external variable that alters the behaviour or output of a simulation system in some way. For example, a system may become less efficient at higher temperatures - the characteristics that describe this behaviour are an operating factor. Operating factors may vary over a range (described by a response profile) and are typically represented in a simulation system as an algorithm component (see above).

Operating Conditions

An operating condition is an external variable that a simulation system depends on in way but that does not have a variable impact on the system. For example, a generator may require fuel to operate. The absence of fuel will mean the generator does not operate but the output of the generator does not otherwise vary with the amount of fuel available. Operating conditions are represented in simulation algorithms as a component or variable, interacting with other components on a simple boolean (true/false) basis.

Engineering Events

An engineering event describes the atypical behaviour of a system in response to contingent conditions, such as damage, overheating or interaction with phenomena.

Engineering events can be included in the simulation to automatically or randomly trigger under certain conditions, such as a system being operated in excess of upper or maximum design limits.

Engineering events may also be triggered manually by the mission operations team, subject to consistency guidelines (there must be an explainable reason and/or cause for the event, even if that is not immediately obvious to the crew).

Engineering events are defined by number of factors:

Probability

For programmatically-triggered events, this defines how likely an event is to occur at a given value of the variable the event is linked to. For example, if an engineering event describes the failure of a system due to operating outside design limits, the probability of that occurring would be lower at operating levels 10% in excess of limits than at 50% in excess.

Target

This defines how an engineering event affects its operating environment. For example, the explosion of a failing component or system may damage all, some or only one of the other components in its immediate environment.

Effect

This defines the effect of an engineering event. For example, a component failure may reduce system output. Some effect types will cause damage, the definition of which will vary depending on the target. For example, an explosion may reduce structural integrity if a bulkhead is the target, whereas if a nearby system is the target it may cause that system to go offline or become unavailable.

Scale

This defines the extent of the engineering event's effect on its target. For example, if the event is a coolant leak, this defines how much coolant is lost. Or, an event simulating damage might reduce a systems' output by a certain amount, cause the system to go offline (until it can be repaired) or make the system unavailable (meaning that system cannot be repaired and must be replaced).