Functional safety and systems engineering glossary

Safety lifecycle

German: Sicherheitslebenszyklus

In functional safety, the safety lifecycle is the sequence of safety activities from concept and design through operation, maintenance, modification, and decommissioning. It makes safety a managed property of the whole life of a system, not a one-time design result.

Functional safety · Systems engineering

Category (ISO 13849-1)

In functional safety of machinery, a Category is the architecture classification of safety-related parts of control systems under ISO 13849-1. The Categories B, 1, 2, 3 and 4 describe the behavior of the system in the event of faults, based on structure, fault detection and component reliability.

Functional safety · Systems engineering

Functional safety

German: Funktionale Sicherheit

In functional safety engineering, functional safety is the part of overall safety that depends on the correct functioning of safety-related control systems. It covers the risk reduction that control functions provide, not guards, inherently safe design or information for use.

Functional safety · Systems engineering

Mean time to dangerous failure (MTTFd)

German: Mittlere Zeit bis zum gefahrbringenden Ausfall (MTTFd)

In functional safety of machinery, the mean time to dangerous failure (MTTFd) is an estimate of the average operating time before a dangerous failure occurs. ISO 13849-1 uses it per channel as one input for determining the Performance Level.

Functional safety · Verification

Performance Level (PL)

German: Performance Level (PL)

In functional safety of machinery, a Performance Level (PL) is a discrete level used in ISO 13849-1 to specify the ability of safety-related parts of control systems to perform a safety function under foreseeable conditions. There are five levels, PL a to PL e, with PL e the highest.

Functional safety · Verification

Probability of dangerous failure per hour (PFHd)

German: Wahrscheinlichkeit eines gefährlichen Ausfalls pro Stunde (PFHd)

In functional safety, the probability of dangerous failure per hour (PFHd) is the average probability per hour that a safety-related system fails dangerously. It is the quantitative measure behind the Performance Level and, for high-demand or continuous operation, the SIL.

Functional safety · Verification

Required Performance Level (PLr)

In functional safety of machinery, the required Performance Level (PLr) is the Performance Level required for a specific safety function based on the risk assessment. It is the target that the achieved Performance Level of that function must meet or exceed.

Functional safety · Verification

Safety Integrity Level (SIL)

German: Sicherheits-Integritätslevel (SIL)

In functional safety, a Safety Integrity Level (SIL) is a discrete level for specifying the safety integrity requirements of a safety function. IEC 61508 defines SIL 1 to SIL 4, and IEC 62061 uses SIL 1 to SIL 3 for machinery.

Functional safety · Verification

Common-cause failure (CCF)

German: Ausfall aufgrund gemeinsamer Ursache (CCF)

In functional safety, a common-cause failure (CCF) is the failure of multiple elements resulting from a single shared cause. It can defeat redundancy, because both channels fail at once.

Functional safety · Systems engineering

Control system

In machine engineering, a control system is the combination of components and logic that commands, regulates, and monitors machine behavior. It includes input devices, logic such as PLCs, and output devices such as contactors, valves and drives.

Functional safety · Integrated systems

Diagnostic coverage (DC)

German: Diagnosedeckungsgrad (DC)

In functional safety, diagnostic coverage (DC) is a measure of the effectiveness of diagnostics in detecting dangerous failures. It is expressed as the share of dangerous failures that the diagnostics detect.

Functional safety · Verification

Diagnostics

In functional safety, diagnostics are functions that detect faults, degraded conditions, or loss of safety capability. They allow the system to react, for example by reaching a safe state or preventing a restart.

Functional safety · Data and interfaces

Diversity (functional safety)

In functional safety, diversity is the use of dissimilar technologies or implementations to reduce susceptibility to common-cause failure. Diverse channels are less likely to fail together from one shared cause.

Functional safety · Systems engineering

Fault exclusion

In functional safety, a fault exclusion is a justified assumption that a specified fault need not be considered because its occurrence is sufficiently unlikely under defined conditions. It is valid only as long as those conditions hold.

Functional safety · Verification

Fault tolerance

German: Fehlertoleranz

In functional safety, fault tolerance is the ability to continue performing a required function in the presence of specified faults. Hardware fault tolerance N means that N + 1 faults can cause loss of the function.

Functional safety · Systems engineering

Programmable logic controller (PLC)

German: Speicherprogrammierbare Steuerung (SPS)

In industrial automation, a programmable logic controller (PLC) is an industrial controller used to automate machine and process functions. A standard PLC is not automatically safety-rated and cannot be assumed to perform safety functions.

Functional safety · Integrated systems

Redundancy

German: Redundanz

In functional safety, redundancy is the use of multiple independent channels or elements so that a single failure does not cause loss of the required function. It is effective only if the channels are sufficiently independent and faults are detected.

Functional safety · Systems engineering

Safety function

German: Sicherheitsfunktion

In functional safety, a safety function is a function whose failure can increase risk and that is implemented to achieve or maintain a safe state. Each safety function is specified with its trigger, reaction, required level (PLr or SIL) and response time.

Functional safety · Systems engineering

Safety PLC

German: Sicherheits-SPS

In functional safety, a safety PLC is a programmable logic controller designed and certified for safety-related control functions. Its internal redundancy, self-tests and certified firmware support safety functions up to the level stated in its certificate, under the conditions of its safety manual.

Functional safety · Integrated systems

Safety relay

German: Sicherheitsrelais

In functional safety, a safety relay is a relay-based device designed to perform and monitor safety-related control functions. Typical safety relays monitor emergency stops, guard interlocks or light curtains, check their own contacts and prevent restart after a fault.

Functional safety · Integrated systems

Safety-related part of a control system (SRP/CS)

In functional safety of machinery, a safety-related part of a control system (SRP/CS) is a part of a control system that responds to safety-related input signals and generates safety-related outputs. Combined SRP/CS for input, logic and output perform a safety function.

Functional safety · Systems engineering

SISTEMA

SISTEMA (Safety Integrity Software Tool for the Evaluation of Machine Applications) is a free software tool from the German IFA that models the safety functions of a machine and calculates their achieved Performance Level under ISO 13849-1, for comparison with the required Performance Level (PLr).

Functional safety · Verification

Final element

German: Aktorik-Subsystem

In process safety under IEC 61511, a final element is the part of a safety instrumented system that implements the physical action needed to achieve or maintain a safe state, for example a shutdown valve with its actuator and solenoid, or a contactor that de-energizes a motor.

Functional safety · Integrated systems

Functional safety management (FSM)

German: Management der funktionalen Sicherheit

In functional safety under IEC 61508 and IEC 61511, functional safety management (FSM) is the set of organizational activities, responsibilities and procedures that ensure the safety lifecycle is planned, carried out, assessed and documented so that the required functional safety is achieved and maintained.

Functional safety · Technical documentation

Hazard and risk analysis (H&RA)

German: Gefährdungs- und Risikoanalyse

In functional safety under IEC 61508 and IEC 61511, hazard and risk analysis (H&RA) is the lifecycle phase that identifies the hazards and hazardous events of a process or equipment, determines their causes, consequences and likelihood, and derives the risk reduction and safety functions required.

Functional safety

Logic solver

German: Logikverarbeitungseinheit

In process safety under IEC 61511, a logic solver is the part of a basic process control system or safety instrumented system that performs one or more logic functions, reading inputs from sensors and commanding final elements.

Functional safety · Integrated systems

Safety instrumented function (SIF)

German: Sicherheitsgerichtete Funktion (SIF)

In process safety under IEC 61511, a safety instrumented function (SIF) is a safety function with a specified safety integrity level, implemented by a safety instrumented system to achieve or maintain a safe state of the process with respect to a specific hazardous event.

Functional safety

Safety instrumented system (SIS)

German: Sicherheitsgerichtetes Instrumentierungssystem (SIS)

In process safety under IEC 61511, a safety instrumented system (SIS) is an instrumented system used to implement one or more safety instrumented functions. It is composed of any combination of sensors, logic solvers and final elements.

Functional safety · Integrated systems

Sensor subsystem

German: Sensor-Subsystem

In functional safety, a sensor subsystem is the part of a safety function that detects the process or machine condition requiring action, comprising the sensors and their input circuits up to the logic solver.

Functional safety · Integrated systems

SIL allocation

German: SIL-Zuordnung

In functional safety under IEC 61511, SIL allocation is the process of allocating risk reduction to protection layers and determining the safety integrity level required for each safety instrumented function, based on the hazard and risk analysis.

Functional safety

Category 1 (ISO 13849-1)

German: Kategorie 1

In ISO 13849-1, Category 1 is a single-channel architecture that meets the requirements of Category B and additionally uses well-tried components and well-tried safety principles. A single fault can still lead to the loss of the safety function, but its occurrence is less likely than in Category B.

Functional safety · Systems engineering

Category 2 (ISO 13849-1)

German: Kategorie 2

In ISO 13849-1, Category 2 is a single-channel architecture with test equipment: it meets Category B, uses well-tried safety principles, and the safety function is checked at suitable intervals by the machine control system. A fault occurring between checks can lead to the loss of the safety function.

Functional safety · Systems engineering

Category 3 (ISO 13849-1)

German: Kategorie 3

In ISO 13849-1, Category 3 is a redundant architecture in which a single fault does not lead to the loss of the safety function, and the single fault is detected whenever reasonably practicable. An accumulation of undetected faults can still lead to the loss of the safety function.

Functional safety · Systems engineering

Category 4 (ISO 13849-1)

German: Kategorie 4

In ISO 13849-1, Category 4 is a redundant architecture in which a single fault does not lead to the loss of the safety function and is detected at or before the next demand. If that is not possible, an accumulation of undetected faults must not lead to the loss of the safety function.

Functional safety · Systems engineering

Category B (ISO 13849-1)

German: Kategorie B

In ISO 13849-1, Category B is the basic single-channel architecture: the safety-related parts are designed to withstand expected influences using basic safety principles, and a single fault can lead to the loss of the safety function.

Functional safety · Systems engineering

Emergency shutdown valve (ESDV)

German: Notabschaltventil

In the process industry, an emergency shutdown valve (ESDV) is an automated on/off valve that moves to its safe position, usually closed, on a demand from the emergency shutdown or safety instrumented system in order to isolate or depressurize part of the plant.

Functional safety · Integrated systems

Performance Level e (PLe)

German: Performance Level e (PLe)

In ISO 13849-1, Performance Level e (PLe) is the highest of the five performance levels, corresponding to an average probability of dangerous failure per hour from 10^-8 to less than 10^-7.

Functional safety · Verification

ProSafe-RS

German: ProSafe-RS

In process automation, ProSafe-RS is the safety instrumented system product line from Yokogawa, used as a logic solver for safety instrumented functions such as emergency shutdown, fire and gas and burner management.

Functional safety · Integrated systems

SafeDESIGNER

German: SafeDESIGNER

In machine automation, SafeDESIGNER is the safety engineering tool from B&R, used within the Automation Studio environment to create and configure safety applications for B&R safety controllers, typically using certified safety function blocks.

Functional safety · Integrated systems

Safety Integrated

German: Safety Integrated

In industrial automation, Safety Integrated is Siemens' name for its approach and product portfolio that integrates functional safety into standard automation, such as fail-safe SIMATIC controllers, PROFIsafe communication and safety functions in SINAMICS drives.

Functional safety · Integrated systems

Safety Manager (Honeywell)

German: Safety Manager

In process automation, Safety Manager is Honeywell's safety instrumented system platform, used as a logic solver for emergency shutdown, fire and gas and burner management functions and typically integrated with Honeywell's Experion control system.

Functional safety · Integrated systems

Safety-related control system (SCS)

German: Sicherheitsbezogenes Steuerungssystem

In functional safety of machinery under IEC 62061, a safety-related control system (SCS) is the part of the control system of a machine that implements a safety function by means of one or more subsystems. Earlier editions used the term safety-related electrical control system (SRECS).

Functional safety · Systems engineering

SIL 3

German: SIL 3

In functional safety under IEC 61508, SIL 3 is the third of four safety integrity levels. It corresponds to an average probability of failure on demand from 10^-4 to less than 10^-3 in low-demand mode, or a probability of dangerous failure per hour from 10^-8 to less than 10^-7 in high-demand or continuous mode.

Functional safety · Verification

MP3300iec (Yaskawa)

German: MP3300iec

The MP3300iec is a Yaskawa machine and motion controller programmed according to IEC 61131-3, used to coordinate servo axes, I/O and machine logic, typically with the vendor's MotionWorks IEC engineering software.

Integrated systems

SIL 1

German: SIL 1

In functional safety under IEC 61508, SIL 1 is the lowest of four safety integrity levels. It corresponds to an average probability of dangerous failure on demand (PFDavg) from 10^-2 to less than 10^-1 in low-demand mode, or an average frequency of dangerous failure (PFH) from 10^-6 to less than 10^-5 per hour in high-demand or continuous mode.

Functional safety · Verification

SIL 2

German: SIL 2

In functional safety under IEC 61508, SIL 2 is the second of four safety integrity levels. It corresponds to an average probability of dangerous failure on demand (PFDavg) from 10^-3 to less than 10^-2 in low-demand mode, or an average frequency of dangerous failure (PFH) from 10^-7 to less than 10^-6 per hour in high-demand or continuous mode.

Functional safety · Verification

SIL 4

German: SIL 4

In functional safety under IEC 61508, SIL 4 is the highest of four safety integrity levels. It corresponds to an average probability of dangerous failure on demand (PFDavg) from 10^-5 to less than 10^-4 in low-demand mode, or an average frequency of dangerous failure (PFH) from 10^-9 to less than 10^-8 per hour in high-demand or continuous mode.

Functional safety · Verification

SIL claim limit (SIL CL)

German: SIL-Anspruchsgrenze (SIL CL)

In functional safety of machinery under IEC 62061, the SIL claim limit (SIL CL) is the maximum safety integrity level that can be claimed for a subsystem, with regard to its architectural constraints and its systematic safety integrity; the SIL of a safety function can't exceed the lowest SIL CL of the subsystems that perform it.

Functional safety · Verification

Systematic capability (SC)

German: Systematische Eignung (SC)

In functional safety under IEC 61508, systematic capability (SC) is a measure, expressed on a scale from SC 1 to SC 4, of the confidence that the systematic safety integrity of an element meets the requirements of a specified SIL, when the element is used as described in its safety manual.

Functional safety · Verification

Demand mode

German: Betriebsart mit niedriger oder hoher Anforderungsrate

In functional safety under IEC 61508, the demand mode or mode of operation describes how often a safety function is called upon: in low-demand mode no more than once per year, in high-demand mode more than once per year, and in continuous mode as part of normal operation; it decides whether the SIL target is expressed as PFDavg or as PFH.

Functional safety · Verification

Average probability of dangerous failure on demand (PFDavg)

German: Mittlere Wahrscheinlichkeit eines gefahrbringenden Ausfalls bei Anforderung (PFDavg)

In functional safety under IEC 61508 and IEC 61511, the average probability of dangerous failure on demand (PFDavg) is the mean unavailability of a safety-related system to perform its safety function when a demand occurs; it is the failure measure used to specify and verify the SIL of low-demand safety functions.

Functional safety · Verification

Alignment check

In functional safety, an alignment check is the verification that a sensing or guarding device remains in its intended physical position and orientation. Misalignment can change detection zones and safety distances even when the device still reports no fault.

Verification · Functional safety

Calibration

German: Kalibrierung

In measurement and verification, calibration is the set of comparison and adjustment activities used to establish measurement accuracy and traceability. Strictly, calibration is the comparison with a reference; adjustment is a separate step that may follow.

Verification · Data and interfaces

Calibration drift

In measurement and verification, calibration drift is the change in measurement accuracy or calibration status over time. It erodes the validity of a calibration long before the next due date if conditions are harsh.

Verification · Data and interfaces

Fault injection

German: Fehlerinjektion

In functional safety verification, fault injection is the deliberate introduction of faults to verify diagnostics, reactions, and degraded behavior. It shows that the system detects the assumed faults and reaches the specified state.

Verification · Functional safety

Field data

In systems engineering and safety, field data is data from actual operation, service, incidents, and maintenance used to validate assumptions and improve controls. It closes the loop between design assumptions and real use.

Verification · Data and interfaces

Functional test

In verification and validation, a functional test is a test that confirms required behavior under defined normal and fault conditions. For safety functions, it checks that the specified trigger leads to the specified reaction within the specified time.

Verification · Functional safety

Measurement traceability

In measurement and verification, measurement traceability is an unbroken, documented chain of calibrations linking a measurement result to recognized references. Each link in the chain contributes to the stated measurement uncertainty.

Verification · Data and interfaces

Periodic verification

In machine safety and functional safety, periodic verification is the scheduled confirmation that a protective measure remains effective in operation. It covers guards, protective devices and safety functions whose performance can degrade over time.

Verification · Functional safety

Post-deployment monitoring

In systems engineering, post-deployment monitoring is monitoring after release or commissioning to detect safety, reliability, security, or evidence issues. It checks whether the assumptions behind the release decision still hold in operation.

Verification · AI

Proof test

German: Wiederholungsprüfung

In functional safety, a proof test is a periodic test intended to reveal hidden dangerous failures and confirm continued safety function capability. After a proof test, the tested function is assumed to be restored to an as-new condition, as far as the test covers it.

Verification · Functional safety

Recalibration

In measurement and verification, recalibration is calibration repeated after time, use, repair, drift, or change to restore or confirm measurement performance. It keeps instruments and sensors within their stated accuracy over their service life.

Verification · Data and interfaces

Sensor drift

German: Sensordrift

In measurement and control, sensor drift is a gradual change in sensor output relative to the measured quantity. It can shift switching thresholds and measured values without triggering any fault message.

Verification · Data and interfaces

Test coverage

In verification and validation, test coverage is the extent to which requirements, functions, states, interfaces, and fault conditions are exercised by tests. It shows what has been tested and, just as important, what has not.

Verification · Systems engineering

Validation

German: Validierung

In functional safety and systems engineering, validation is the confirmation through examination and objective evidence that the safety solution fulfills its intended use and requirements. It asks whether the right solution was built for the real application.

Verification · Functional safety

Validation plan

In functional safety, a validation plan is a documented plan defining validation methods, responsibilities, test conditions, criteria, and evidence. It is written before validation starts so that results can be judged against predefined expectations.

Verification · Technical documentation

Verification

German: Verifizierung

In functional safety and systems engineering, verification is the confirmation through examination and objective evidence that specified requirements have been fulfilled. It checks each work product against its specification.

Verification · Systems engineering

Proof-test interval

German: Wiederholungsprüfintervall

In functional safety, the proof-test interval is the time between two proof tests of a safety function or its components. It is a parameter of the failure probability calculation, because dangerous undetected failures can remain hidden until the next proof test.

Verification · Functional safety

SIL validation

German: SIL-Validierung

In functional safety under IEC 61511, SIL validation (SIS safety validation) is the activity of demonstrating, by inspection and testing of the installed and commissioned system, that the safety instrumented system and its functions meet the safety requirements specification.

Verification · Functional safety

SIL verification

German: SIL-Verifikation

In functional safety, SIL verification is the demonstration that a designed safety function meets its required safety integrity level, covering the failure measure (PFDavg or PFH), the architectural constraints such as hardware fault tolerance, and the systematic capability of its elements.

Verification · Functional safety

Verification method

German: Verifikationsmethode

In systems engineering, a verification method is the way in which a requirement is shown to be met; the classic methods are inspection, analysis, demonstration and test, sometimes complemented by review or similarity.

Verification · Systems engineering

PASCAL Safety Calculator

German: PASCAL Safety Calculator

In functional safety of machinery, PASCAL Safety Calculator is a software tool from Pilz for calculating and verifying the achieved Performance Level to ISO 13849-1 and the SIL to IEC 62061 of safety functions, using component libraries with reliability data.

Functional safety · Verification

Safety claim

In safety assurance, a safety claim is a testable assertion about safety, risk reduction, or system behavior that requires supporting evidence. It states what is protected, against which hazard and under which conditions.

Functional safety · Verification

Assurance case

In systems assurance, an assurance case is a structured argument, supported by evidence, that a system is acceptably safe for a defined application and environment. It links a top-level claim through subclaims and reasoning to the evidence.

Systems engineering · Verification

Digital thread

In systems engineering, a digital thread is a connected information path across the lifecycle from requirements and risks to design, tests, documentation, and field data. It links data held in different tools so that each item can be followed to its origins and consequences.

Systems engineering · Data and interfaces

Evidence architecture

In safety assurance, an evidence architecture is the structure connecting requirements, hazards, controls, tests, documentation, operation, and changes into a coherent assurance case. It defines which item types exist, how they link and where each is stored.

Systems engineering · Technical documentation

Evidence chain

In safety assurance, an evidence chain is the linked sequence from a requirement or hazard through the design decision, implementation, verification, and user information. A break anywhere in the chain leaves the claim unsupported.

Systems engineering · Technical documentation

Evidence package

In safety assurance, an evidence package is a controlled set of related evidence supporting a claim, function, risk control, or change. It bundles the items, their versions and their links so that a reviewer can assess them together.

Technical documentation · Verification

Lifecycle claim

In assurance and systems engineering, a lifecycle claim is a claim that must remain valid through operation, maintenance, updates, and modifications, not only at release. It needs evidence that is kept current over time.

Systems engineering · Verification

Residual risk evidence

In safety assurance, residual risk evidence is the evidence showing how remaining risks were evaluated, communicated, accepted, and monitored. It connects the end of risk reduction to the information given to users and to field monitoring.

Functional safety · Technical documentation

Safety evidence

In safety assurance, safety evidence is the records, test results, analyses, approvals, and other artifacts that support a safety claim. Evidence counts only when it is identifiable, controlled and linked to the claim and to the version it applies to.

Functional safety · Technical documentation

Trace link

In systems engineering, a trace link is an explicit, typed relationship between two lifecycle items, such as a requirement and its verification evidence. The type states what the link means, for example “verified by”, “mitigated by” or “derived from”.

Systems engineering · Data and interfaces

Traceability

German: Rückverfolgbarkeit

In systems engineering and safety, traceability is the ability to follow relationships among requirements, hazards, controls, tests, changes, and documentation. It works in both directions: from a hazard to its verified controls, and from a document back to the hazards it addresses.

Systems engineering · Technical documentation

Assumption (systems engineering)

German: Annahme

In systems engineering, an assumption is a documented condition taken as true for a requirement, analysis, design, test, or claim. Assumptions are not proven within the work that uses them, so they must be stated, owned and monitored.

Systems engineering · Verification

Claim (assurance)

In assurance and systems engineering, a claim is a reviewable assertion about system behavior, safety, security, or compliance that requires evidence. A claim is only as strong as the evidence and reasoning linked to it.

Systems engineering · Verification

Safety plan

German: Sicherheitsplan

In functional safety under IEC 61508 and IEC 61511, a safety plan is the document that defines the activities, responsibilities, procedures, schedule and deliverables needed to carry out the safety lifecycle phases for a specific project or system.

Functional safety · Technical documentation

Bidirectional traceability

German: Bidirektionale Rückverfolgbarkeit

In systems engineering, bidirectional traceability means that trace links can be followed in both directions: forward from a requirement to its design elements, implementation and tests, and backward from any design element or test to the requirement that justifies it.

Systems engineering · Verification

Requirements traceability

German: Anforderungsrückverfolgbarkeit

In systems engineering, requirements traceability is the ability to follow the life of a requirement through documented links: back to its source (stakeholder need, regulation, hazard) and forward to derived requirements, design elements, implementation and verification results.

Systems engineering · Verification

Quality assurance

German: Qualitätssicherung

In quality management according to ISO 9000, quality assurance is the part of quality management focused on providing confidence that quality requirements will be fulfilled, through planned and systematic activities such as reviews, audits, process controls and records.

Verification · Functional safety

Backward compatibility

German: Abwärtskompatibilität

In systems engineering, backward compatibility is the controlled ability of a new version to work with older data, interfaces or peer systems. It is a defined and tested property, not an assumption that old inputs will still be handled.

Data and interfaces · Systems engineering

Behavior version

In systems engineering, a behavior version is the version of the state, reaction and fault logic of a system or interface. It changes when the system reacts differently, even if the data format and protocol stay the same.

Data and interfaces · Systems engineering

Breaking change

In systems engineering, a breaking change is a change that may invalidate existing interfaces, behavior, tests, assumptions, documentation or evidence. It is defined by its possible effect on dependents, not by the size of the change.

Data and interfaces · Systems engineering · Verification

Data model version

In systems engineering, a data model version is the version of the semantic data structure, including its fields, meanings, units, ranges and enumerations. It changes when the meaning of data changes, not only when its format does.

Data and interfaces · Systems engineering

Deprecation path

In systems engineering, a deprecation path is a controlled plan for announcing, replacing, migrating and removing an old version or function. It gives dependents a defined period and a defined route to move away from what is being retired.

Data and interfaces · Systems engineering · Technical documentation

Evidence version

In functional safety and systems engineering, an evidence version is the version of the valid evidence state for requirements, tests, logs, claims and results. It records which set of evidence belongs to which system version.

Verification · Functional safety · Technical documentation

Forward compatibility

German: Vorwärtskompatibilität

In systems engineering, forward compatibility is the controlled ability of a current system to handle future or extended interface and data versions. It requires a defined rule for what the system does with content it does not recognize.

Data and interfaces · Systems engineering

Protocol version

In systems engineering, a protocol version is the version of the communication rules used between systems. It identifies which message structure, sequence, timing and error-handling rules apply to an exchange.

Data and interfaces · Systems engineering

Rollback capability

In systems engineering, rollback capability is the ability to return to a previous valid system, configuration, documentation and evidence state after a change. A rollback is only complete when all four states match again.

Systems engineering · Functional safety · Technical documentation

Version compatibility

In systems engineering, version compatibility is the defined ability of system or interface versions to work together without unacceptable behavior. It is stated as a matrix of versions that have been specified and verified to work together.

Data and interfaces · Systems engineering · Verification

Configuration control

In systems engineering, configuration control is the governance of approved hardware, software, parameter, model, document and evidence configurations. It ensures that only authorized configurations are built, installed and supported.

Systems engineering · Functional safety · Technical documentation

Release decision

In systems engineering, a release decision is a controlled decision that a defined system and evidence baseline is ready for use, delivery or operation. It is taken by an authorized person or body on the basis of documented criteria.

Verification · Systems engineering · Technical documentation

Change control

German: Änderungssteuerung

In systems engineering, change control is a governed process for proposing, assessing, approving, implementing and verifying changes. It ensures that no change reaches an approved configuration without an assessment of its effects.

Systems engineering · Functional safety · Technical documentation

Change propagation

In systems engineering, change propagation is the controlled transfer and evaluation of a change across dependent lifecycle items. It follows trace links from the changed item to every requirement, design, test, document and evidence item that depends on it.

Systems engineering · Technical documentation · Integrated systems

Configuration baseline

German: Konfigurationsbasis

In configuration management, a configuration baseline is an approved snapshot of hardware, software, configuration, models, documentation and evidence at a defined point in time. Later changes are made and assessed against it.

Systems engineering · Verification · Technical documentation

Impact analysis

In systems engineering and functional safety, impact analysis is the analysis of which requirements, risks, interfaces, tests, documents and operations may be affected by a change. It determines the scope of reassessment and re-verification.

Systems engineering · Functional safety · Verification

Management of change (MOC)

In occupational and process safety, management of change (MOC) is a formal process for assessing, approving, implementing and verifying technical or organizational changes. It covers changes to equipment and processes as well as to procedures, staffing and responsibilities.

Systems engineering · Functional safety

Change request

German: Änderungsantrag

In systems engineering and configuration management, a change request is a formal, identified proposal to modify a baselined item such as a requirement, design, software version or document; it records the reason, the proposed change and the decision taken on it.

Systems engineering · Technical documentation

Deviation management

German: Abweichungsmanagement

In engineering and quality management, deviation management is the controlled process of recording, assessing, approving or rejecting and closing departures from a specification, requirement, procedure or plan, including the decision whether the deviation is accepted, corrected or triggers a change.

Systems engineering · Verification

End-of-life plan

German: Abkündigungsplan

In product lifecycle management, an end-of-life plan defines how a product, component or software version is discontinued: announcement dates, last-time-buy, end of sales, end of support and security updates, spare-parts availability and recommended successors.

Systems engineering · Technical documentation

Requirement baseline

German: Anforderungsbasis

In systems engineering, a requirement baseline is a formally reviewed and approved set of requirements, frozen at a point in time, that serves as the reference for design, verification and contract; it can only be changed through change control.

Systems engineering

Version release

German: Versionsfreigabe

In configuration management, a version release is the formal approval and publication of a specific, identified version of a product, software, firmware or document for use, after its verification and approval steps are complete.

Systems engineering · Technical documentation

System boundary

German: Systemgrenze

In systems engineering, a system boundary is the defined limit that identifies which components, interfaces, operating assumptions and responsibilities belong to the assessed system. Everything outside it is treated as environment or as a separate system with its own responsibilities.

Systems engineering · Integrated systems · German source term

Assembly of machinery

German: Gesamtheit von Maschinen

Under the EU Machinery Regulation, an assembly of machinery consists of machines or partly completed machinery that are arranged and controlled so that they function as an integral whole. The assembly as a whole is itself treated as machinery.

Integrated systems · Functional safety · German source term

Coupling analysis

German: Kopplungsanalyse

In systems engineering, coupling analysis is the analysis of how connected machines, functions, hazards, failures and controls influence one another. It looks for effects that arise only through the connection.

Integrated systems · Functional safety · German source term

Engineering information model

German: Engineering-Informationsmodell

In systems engineering, an engineering information model is a structured model linking requirements, functions, system elements, risks, assumptions, tests and evidence. It defines which kinds of items exist and how they may be related.

Systems engineering · Data and interfaces · Technical documentation · German source term

Integrated system

German: integriertes System

In systems engineering, an integrated system is a system in which multiple machines, subsystems, software elements and interfaces interact to produce system-level behavior. Its behavior cannot be fully derived from the behavior of its parts assessed in isolation.

Integrated systems · Systems engineering · German source term

Interaction hazard

In machine safety and systems engineering, an interaction hazard is a hazard created or changed by interaction between system elements or machines. It does not exist, or exists differently, when each element is considered on its own.

Integrated systems · Functional safety

Lifecycle state

In systems engineering, a lifecycle state is the controlled status of a system or artifact, such as draft, approved, validated, modified, deprecated or retired. It tells users whether an item may be relied on and for what.

Systems engineering · Technical documentation

Model element

In model-based systems engineering, a model element is a uniquely identifiable item in a model, such as a function, component, requirement, risk, interface or test. Its identity stays stable when its name or content changes.

Systems engineering · Data and interfaces

Model governance

In model-based engineering, model governance is the set of rules defining who creates, changes, reviews, approves, versions and audits models. It makes models trustworthy enough to serve as evidence.

Systems engineering · Verification

Model-Based Engineering (MBE)

In engineering, Model-Based Engineering (MBE) is an approach in which models are the primary working and evidence artifacts. Documents are derived from models rather than being the reference themselves.

Systems engineering · Data and interfaces

Model-Based Systems Engineering (MBSE)

German: Modellbasiertes Systems Engineering (MBSE)

In systems engineering, Model-Based Systems Engineering (MBSE) is an approach using connected models of requirements, functions, architecture, interfaces, behavior and evidence. The system model, rather than a set of documents, is the reference for the system.

Systems engineering · Integrated systems

Operating assumption

German: Betriebsannahme

In systems engineering, an operating assumption is a documented condition under which the system is expected to operate correctly, such as network, timing, role or maintenance conditions. If the condition does not hold, the analyses and evidence that rely on it may no longer be valid.

Systems engineering · Functional safety · German source term

Operating mode

German: Betriebsart

In machine safety, an operating mode is a defined mode that determines permitted functions, controls, access and protective behavior. Examples are automatic mode, setting mode and maintenance mode, each with its own safety measures.

Functional safety · Systems engineering · German source term

Operational feedback

In systems engineering, operational feedback is information from operation, service, incidents and users that may trigger updates to risks, requirements, controls or documentation. It closes the loop between the field and engineering.

Systems engineering · Functional safety · Technical documentation

Responsibility assignment

German: Verantwortlichkeit

In systems engineering, a responsibility assignment is a defined allocation of who operates, changes, approves, verifies and supplies evidence for a system or interface. It makes responsibility explicit per item and per activity.

Systems engineering · Integrated systems · German source term

Safety profile

German: Sicherheitsprofil

In functional safety and systems engineering, a safety profile is the set of active safety assumptions, permissions, limits and protective functions for a defined operating context. Switching the context switches the profile as a whole.

Functional safety · Integrated systems · German source term

Shared safety zone

In machine safety and systems engineering, a shared safety zone is a hazardous or protected area whose safety depends on coordinated behavior across multiple machines or controls. No single machine can make the zone safe on its own.

Integrated systems · Functional safety

Source of truth

German: Datenhoheit

In systems engineering, a source of truth is the authoritative source for a defined information type, including its ownership, approval and conflict-resolution rules. Copies elsewhere are derived and yield to it when they disagree.

Data and interfaces · Systems engineering · Technical documentation · German source term

Subsystem

In systems engineering, a subsystem is a defined part of a larger system that performs one or more functions. It has its own boundary and interfaces to the rest of the system.

Systems engineering · Integrated systems

System element

In systems engineering, a system element is an identifiable component, subsystem, function, interface, requirement, risk or evidence item within a system model. It is the unit that can be named, linked, versioned and verified.

Systems engineering · Data and interfaces

System mode

German: Systemart

In systems engineering, a system mode is a state describing the technical configuration or overall operational condition of an integrated system. Examples are production, changeover, commissioning, degraded operation and shutdown.

Integrated systems · Systems engineering · German source term

System model

German: Systemmodell

In systems engineering, a system model is a model connecting system elements, relationships, functions, requirements, states and behavior. It is the central artifact of model-based systems engineering.

Systems engineering · Integrated systems

View (systems engineering)

In systems engineering, a view is a representation of a system model selected for a specific purpose or stakeholder. It shows only the elements and relationships that matter for that purpose and follows the conventions of a viewpoint.

Systems engineering · Technical documentation

Viewpoint (systems engineering)

In systems engineering, a viewpoint is the set of conventions and concerns that define how a view is constructed and interpreted. It specifies the stakeholders and concerns addressed, the model kinds used and the rules for reading them.

Systems engineering · Technical documentation

Concept of operations (ConOps)

German: Betriebskonzept (ConOps)

In systems engineering, a concept of operations (ConOps) is a document that describes, from the users' and operators' point of view, how a system is intended to be used, in which environments and operating modes, by whom, and how it fits into the organization's operations.

Systems engineering

Software design specification (SDS)

German: Softwaredesignspezifikation (SDS)

In software engineering, a software design specification (SDS) describes how the software will be built to meet its requirements: architecture, modules or function blocks, interfaces, data structures, algorithms and error handling.

Systems engineering · Technical documentation

Systems engineering management plan (SEMP)

German: Systems-Engineering-Managementplan (SEMP)

In systems engineering, a systems engineering management plan (SEMP) describes how the technical work of a project is organized and controlled: lifecycle model, technical reviews, requirements and configuration management, verification approach, tools, roles and deliverables.

Systems engineering

Activity diagram

German: Aktivitätsdiagramm

In SysML and UML, an activity diagram is a behavior diagram that shows the flow of actions, control and objects (material, energy, data) through a process, including decisions, parallel paths and the elements responsible for each action.

Systems engineering

Block definition diagram (BDD)

German: Blockdefinitionsdiagramm (BDD)

In SysML, a block definition diagram (BDD) is a structure diagram that defines blocks and their relationships, such as composition, generalization and association, together with their properties, ports and operations.

Systems engineering

Internal block diagram (IBD)

German: Internes Blockdiagramm (IBD)

In SysML, an internal block diagram (IBD) is a structure diagram that shows the internal structure of one block: its parts, their ports and the connectors and item flows (signals, data, energy, material) between them.

Systems engineering · Data and interfaces

Requirement diagram

German: Anforderungsdiagramm

In SysML, a requirement diagram shows requirements as model elements and their relationships to each other and to other model elements, such as containment, derive, refine, satisfy, verify and trace.

Systems engineering · Verification

Sequence diagram

German: Sequenzdiagramm

In SysML and UML, a sequence diagram is a behavior diagram that shows the interaction between elements as a time-ordered exchange of messages along their lifelines.

Systems engineering · Data and interfaces

State machine diagram

German: Zustandsdiagramm

In SysML and UML, a state machine diagram is a behavior diagram that shows the states of an element, the events and conditions that trigger transitions between them, and the actions performed on entry, exit or during a state.

Systems engineering

SysML block

German: SysML-Block

In SysML, a block is the basic modular unit of structure; it can represent a system, subsystem, component, software item, person or physical item and carries properties, ports, operations and behavior.

Systems engineering

Systems Modeling Language (SysML)

German: Systems Modeling Language (SysML)

The Systems Modeling Language (SysML) is a general-purpose modeling language for systems engineering, standardized by the Object Management Group (OMG), used to specify, analyze, design and verify systems with requirements, structure, behavior and parametric constraints.

Systems engineering

Use case diagram

German: Anwendungsfalldiagramm

In SysML and UML, a use case diagram is a behavior diagram that shows the functionality a system provides (use cases) and the actors, such as people or external systems, that interact with it.

Systems engineering

Open systems

German: Offene Systeme

In automation, open systems are control and communication systems based on published, vendor-independent standards and interfaces, so that components from different manufacturers can be combined, exchanged and integrated.

Integrated systems · Data and interfaces

Engineering unit

In systems engineering, an engineering unit is the unit and scaling used to interpret a measured or commanded value. A raw number at an interface has no reliable meaning until its engineering unit is defined.

Data and interfaces · Systems engineering

Protocol (communication)

In systems engineering, a protocol is a set of technical rules for communication between systems, such as message structure, sequence, addressing, timing and error handling. It governs how data is exchanged, not what the data means.

Data and interfaces · Systems engineering

Acceptance criterion

In systems engineering, an acceptance criterion is a condition used to determine whether a result is acceptable for its intended stakeholder or use. It expresses what the stakeholder will accept, which may go beyond fulfilling a single requirement.

Verification · Systems engineering

Verification criterion

In systems engineering, a verification criterion is a measurable condition used to determine whether a requirement has been fulfilled. It states what is measured, how, and which result counts as a pass.

Verification · Systems engineering

Constraint (systems engineering)

German: Randbedingung

In systems engineering, a constraint is a limitation that restricts permissible design or operation, such as a standard, interface, environment or technology condition. It narrows the solution space rather than describing a function.

Systems engineering · Data and interfaces

Functional requirement

German: Funktionale Anforderung

In systems engineering, a functional requirement is a requirement defining what the system must do. It describes a function, a transformation or a reaction to an input or event.

Systems engineering · Verification

Interface (systems engineering)

German: Schnittstelle

In systems engineering, an interface is a defined boundary across which systems exchange energy, material, data, commands, states or responsibility. An interface has two sides, and each side has an owner.

Data and interfaces · Integrated systems · German source term

Interface control document (ICD)

German: Schnittstellenkontrolldokument (ICD)

In systems engineering, an interface control document (ICD) is a controlled document defining the technical and organizational requirements of an interface. It is agreed by the owners of both sides and changed only under change control.

Data and interfaces · Technical documentation · Systems engineering

Interface specification

German: Schnittstellenspezifikation

In systems engineering, an interface specification is a controlled definition of normal behavior, fault behavior, timing, data meaning, limits and responsibilities at an interface. It is detailed enough to design and test both sides against it.

Data and interfaces · Systems engineering · Verification

Nonfunctional requirement

German: Nichtfunktionale Anforderung

In systems engineering, a nonfunctional requirement is a requirement defining qualities or constraints such as timing, safety, security, usability, availability, maintainability or resilience. It describes how well or under which conditions the system performs its functions.

Systems engineering · Verification

Requirement

In systems engineering, a requirement is a documented need or condition that a system or process must satisfy. A good requirement is unambiguous, verifiable and traceable to its source.

Systems engineering · Verification

Stakeholder requirement

German: Stakeholder-Anforderung

In systems engineering, a stakeholder requirement is a stakeholder need or expectation that may require refinement before it is technically verifiable. It is expressed in the stakeholder's terms and is the origin of derived system requirements.

Systems engineering · Verification

System requirement

German: Systemanforderung

In systems engineering, a system requirement is a derived, verifiable requirement for system behavior or performance. It translates stakeholder needs into technical terms against which the system can be designed and verified.

Systems engineering · Verification

Safety integrity requirement

German: Anforderung an die Sicherheitsintegrität

In functional safety under IEC 61508, a safety integrity requirement specifies how reliably a safety function must be performed, expressed as a safety integrity level with its target failure measure. It complements the functional requirement, which states what the safety function does.

Functional safety · Systems engineering

Safety requirements specification (SRS)

German: Spezifikation der Sicherheitsanforderungen (SRS)

In functional safety under IEC 61508 and IEC 61511, the safety requirements specification (SRS) is the document that states the functional and safety integrity requirements of each safety function, including trip conditions, safe states, response times, required SIL and test requirements.

Functional safety · Technical documentation

Functional design specification (FDS)

German: Funktionale Designspezifikation (FDS)

In automation projects, a functional design specification (FDS) describes how the control system will implement the required functions: sequences, operating modes, interlocks, alarms, HMI behavior and interfaces, written so that the customer can review and approve it before programming starts.

Systems engineering · Technical documentation

Hardware requirement

German: Hardwareanforderung

In systems engineering, a hardware requirement is a requirement allocated to a hardware element, stating a physical, electrical, mechanical or environmental characteristic it must have, such as supply voltage, I/O count, protection rating, temperature range or response time.

Systems engineering

Interface requirement

German: Schnittstellenanforderung

In systems engineering, an interface requirement specifies what must be exchanged or matched across the boundary between two system elements or systems: signals, data, protocols, timing, physical connections, power or mechanical fit.

Systems engineering · Data and interfaces

Performance requirement

German: Leistungsanforderung

In systems engineering, a performance requirement states how well a system or element must perform a function, expressed as a measurable quantity with limits, such as throughput, cycle time, accuracy, response time or availability.

Systems engineering

Requirement attribute

German: Anforderungsattribut

In requirements engineering, a requirement attribute is a piece of metadata attached to a requirement, such as identifier, source, priority, owner, status, verification method, safety relevance or version, used to manage, filter and trace it.

Systems engineering · Data and interfaces

Requirement identifier

German: Anforderungskennung

In requirements engineering, a requirement identifier is a unique, stable label assigned to a requirement so it can be referenced, traced and discussed unambiguously throughout its lifecycle, independent of its wording or position in a document.

Systems engineering · Data and interfaces

Requirement status

German: Anforderungsstatus

In requirements engineering, requirement status is an attribute that shows where a requirement stands in its lifecycle, for example proposed, approved, implemented, verified, rejected or deleted.

Systems engineering

Software requirement

German: Softwareanforderung

In systems engineering, a software requirement is a requirement allocated to software, stating a function, behavior, performance, interface or constraint the software must meet.

Systems engineering

Software requirements specification (SRS)

German: Softwareanforderungsspezifikation (SRS)

In software engineering, a software requirements specification (SRS) is the document or model that collects all requirements for a software product or component, including functions, interfaces, performance, constraints and quality attributes, in a form that can be reviewed and verified.

Systems engineering · Technical documentation

Subsystem requirement

German: Subsystemanforderung

In systems engineering, a subsystem requirement is a requirement allocated to a subsystem, derived from system requirements, that the subsystem must meet so the overall system can meet its own requirements.

Systems engineering

Residual interface

German: Restschnittstelle

In automation projects, a residual interface is the interface that remains between a newly engineered, migrated or replaced part of a plant or machine and the unchanged existing part, and that must be defined and tested so both work together.

Data and interfaces · Integrated systems

Touchscreen

German: Touchscreen

In automation, a touchscreen is a display that detects touch input and is used as the operating element of an HMI panel, allowing operators to view process information and enter commands directly on the screen.

Integrated systems · Data and interfaces

Fallback

In systems engineering, a fallback is a defined alternative behavior used when the preferred function or dependency is unavailable. It is specified in advance, not improvised at runtime.

Integrated systems · Functional safety

Fault reaction

In functional safety, a fault reaction is the defined system response to a detected fault, for example switching to a safe state, entering a degraded mode or raising an alarm.

Functional safety · Integrated systems

Partial failure

In systems engineering, a partial failure is a condition in which only part of an integrated system or transaction fails while other parts continue to operate.

Integrated systems · Functional safety

Reaction chain

German: Reaktionskette

In functional safety, a reaction chain is the linked sequence from detection through decision and control action to the achieved system state, for example sensor, logic, actuator and the machine reaching a safe state.

Functional safety · Integrated systems · German source term

Recovery behavior

In systems engineering, recovery behavior is the defined behavior for restoring operation after a fault, stop or degraded condition, including the checks, resets and resynchronization needed before normal operation resumes.

Functional safety · Integrated systems

Safe default

In functional safety, a safe default is a predefined value or behavior selected to reduce risk when information is missing, invalid or uncertain.

Functional safety · Data and interfaces

State model

German: Zustandsautomat

In systems engineering, a state model is a model of the defined states of a system and the permitted transitions between them, including the conditions that trigger each transition.

Systems engineering · Functional safety

State transition

In systems engineering, a state transition is a change from one defined system state to another under specified conditions, such as an event, a command or an elapsed time.

Systems engineering · Functional safety

Degraded mode

In functional safety and systems engineering, degraded mode is a controlled operating condition with reduced capability following a fault or the loss of a dependency. The reduction is planned and its limits are defined.

Functional safety · Integrated systems

Fail-operational behavior

In functional safety, fail-operational behavior is behavior in which operation continues, possibly in a degraded mode, despite specified faults. It requires redundancy or fault tolerance for the functions that must keep working.

Functional safety · Systems engineering

Fail-safe behavior

In functional safety, fail-safe behavior is behavior in which a fault causes or maintains a safe state. The design ensures that the expected failure modes lead toward safety rather than away from it.

Functional safety · Systems engineering

Hardware fault tolerance (HFT)

German: Hardware-Fehlertoleranz (HFT)

In functional safety under IEC 61508 and IEC 61511, hardware fault tolerance (HFT) is the ability of a subsystem to continue to perform its safety function in the presence of hardware faults. An HFT of N means that N+1 faults could cause the loss of the safety function.

Functional safety

Safe failure fraction (SFF)

German: Anteil sicherer Ausfälle (SFF)

In functional safety under IEC 61508, the safe failure fraction (SFF) of an element is the ratio of the sum of its safe failure rate and dangerous detected failure rate to its total failure rate. Together with hardware fault tolerance, it is used to determine architectural constraints.

Functional safety

Remanence (retentive memory)

German: Remanenz

In PLC programming, remanence is the property of variables or memory areas that keep their values after a power failure or controller restart, as opposed to non-retentive data that are reset to initial values; IEC 61131-3 declares such variables as RETAIN.

Data and interfaces

Backoff

In systems engineering, backoff is a controlled delay strategy between retries that prevents overload of a system or repeated conflict between senders. Common forms are fixed, linear and exponential backoff, often with a random component.

Data and interfaces · Integrated systems

Buffering

In systems engineering, buffering is the temporary storage of data or events before they are processed or transmitted. A buffer decouples producers and consumers that work at different rates or are briefly unavailable.

Data and interfaces · Integrated systems

Closed-loop control

German: Regelung mit Rückführung

In control engineering, closed-loop control is control that uses feedback to compare the actual behavior of a process with the intended result and corrects its output based on the difference.

Systems engineering · Integrated systems

Data validation

In systems engineering, data validation is the set of checks that confirm data meets defined structural, semantic, range, timing and quality rules before it is used. It tests the data, not whether a system fulfills its intended use.

Data and interfaces · Integrated systems · Verification

Event-driven communication

In systems engineering, event-driven communication is a communication pattern in which data is sent when a defined event or state change occurs, rather than at fixed intervals or on request.

Data and interfaces · Integrated systems

Feedback signal

In control engineering, a feedback signal is a signal that represents measured system behavior and is used for monitoring or control, for example a position, speed, pressure or contact state.

Functional safety · Data and interfaces

Idempotency

German: Idempotenz

In systems engineering, idempotency is the property that repeating the same operation has the same effect as performing it once. It makes retries and duplicate messages harmless.

Data and interfaces · Integrated systems

Jitter

German: Jitter

In systems engineering, jitter is the variation in latency or timing between repeated events or communications, such as the spread of arrival times of a cyclic message.

Data and interfaces · Integrated systems

Latency

German: Latenz

In systems engineering, latency is the delay between an event, transmission, processing step, command, response or documentation update and the point at which it takes effect or becomes available.

Data and interfaces · Integrated systems · Technical documentation

Open-loop control

German: Steuerung ohne Rückführung

In control engineering, open-loop control is control that does not use feedback to confirm the effect of its output. The controller issues a command and assumes that the process follows it.

Systems engineering · Integrated systems

Plausibility check

In functional safety and systems engineering, a plausibility check is a rule-based check that evaluates whether a value or state is credible in context, for example by comparing it with physical limits, rates of change or related signals.

Functional safety · Data and interfaces

Polling

German: Polling

In systems engineering, polling is a communication pattern in which a system repeatedly requests current information from another system, typically at a fixed interval.

Data and interfaces · Integrated systems

Quality status

In industrial data exchange, a quality status is metadata indicating whether a data value is valid, uncertain, bad, substituted or stale. It travels with the value so that the consumer can decide whether to use it.

Data and interfaces · Integrated systems

Retry

In systems engineering, a retry is a repeated attempt after a failed or missing communication or operation, usually bounded by a maximum number of attempts.

Data and interfaces · Integrated systems

Stale data

In systems engineering, stale data is data that is structurally valid but too old to support the intended decision safely. Whether data is stale depends on its age and on the decision it is used for.

Data and interfaces · Functional safety

Store-and-forward

In systems engineering, store-and-forward is a communication method that stores information until it can be transmitted to the next system, so that data survives a temporary loss of connection.

Data and interfaces · Integrated systems

Time synchronization

German: Zeitsynchronisierung

In systems engineering, time synchronization is the coordination of clocks across system elements so that events and data can be interpreted consistently, for example with the Network Time Protocol (NTP) or the Precision Time Protocol (PTP).

Data and interfaces · Integrated systems

Timeout

In systems engineering, a timeout is a defined time limit after which a missing response is treated as a fault or exception.

Data and interfaces · Functional safety

Timestamp

German: Zeitstempel

In systems engineering, a timestamp is the recorded time associated with an event, value, command or state. It states when something happened or was measured, which is not necessarily when it was received.

Data and interfaces · Integrated systems

openSAFETY

German: openSAFETY

In industrial communication, openSAFETY is an open, fieldbus-independent safety protocol for transmitting safety-related data over standard networks according to the black channel principle. It is specified as a functional safety communication profile in IEC 61784-3.

Functional safety · Data and interfaces

PROFIsafe

German: PROFIsafe

In industrial communication, PROFIsafe is the functional safety communication profile for PROFIBUS and PROFINET, specified in IEC 61784-3. It transmits safety-related data between safety controllers and safety devices over the standard network according to the black channel principle.

Functional safety · Data and interfaces

Electronic device description (EDD)

German: Electronic Device Description (EDD)

In process automation, an electronic device description (EDD) is a file written in the Electronic Device Description Language (EDDL) that describes the parameters, functions, menus and data structures of a field device, so that host systems can configure and diagnose it without device-specific software.

Data and interfaces

Intelligent field device

German: Intelligentes Feldgerät

In industrial automation, an intelligent field device is a sensor or actuator with its own microprocessor that, besides its primary measuring or actuating function, provides digital communication, parameterization, diagnostics and often additional measured values.

Data and interfaces · Integrated systems

Key Performance Indicator (KPI)

German: Key Performance Indicator (KPI)

In manufacturing and automation, a key performance indicator (KPI) is a defined, measurable value calculated from production data that shows how well a process, machine or organization achieves a goal, for example overall equipment effectiveness (OEE), availability or scrap rate.

Data and interfaces

NAMUR Open Architecture (NOA)

German: NOA (NAMUR Open Architecture)

In process automation, the NAMUR Open Architecture (NOA) is a concept that adds a second, open communication channel to the existing core process control, so that field and plant data can be used for monitoring and optimization without compromising the availability and safety of the core automation.

Data and interfaces · Integrated systems

Normalization (signal scaling)

German: Normierung

In automation, normalization is the conversion of a raw value, such as an analog input count, into a normalized range (for example 0.0 to 1.0) or, together with scaling, into an engineering value with a unit, so that the control program works with meaningful, comparable values.

Data and interfaces

Performance (automation system)

German: Performance

In automation, performance describes how well a system or component carries out its functions in measurable terms, such as cycle time, throughput, response time, accuracy or communication load.

Data and interfaces

Serial interface

German: Serielle Schnittstelle

In automation, a serial interface transmits data one bit after another over a single line or line pair, for example RS-232, RS-422 or RS-485, and is used to connect devices such as barcode readers, scales, drives or legacy controllers.

Data and interfaces

Trace (signal recording)

German: Trace

In PLC and drive engineering, a trace is a time-based recording of selected variables or signals, triggered by a defined condition and sampled at a fixed rate, used for commissioning, optimization and troubleshooting.

Data and interfaces · Verification