Skip to content

Functional layer

The question this layer answers

What must the system do?

The functional layer states the system's responsibilities without choosing how to meet them. A function here is technology-independent. Software, electronics, mechanics or a human procedure may carry it out, and choosing which is a later layer's decision.

Following ARCADIA, functions form a chain. Functions of the whole system decompose until each piece is the responsibility of exactly one component. MEMO names the two ends of that chain because they obey different rules.

Namespace: memo::architecture::functional · Source: src/architecture/functional/

Key elements

Functions. A SystemFunction is a responsibility of the system as a whole. Allocating it is optional: a system function that no single component owns is a normal intermediate state of the chain, and it may be realised by several components, by a human, or by a mechanism. A ComponentFunction is a responsibility of exactly one component, so it must be allocated, and to one component only. Both specialise MemoFunction, which carries:

  • actionKind, the verb, such as sense, compute, actuate or route;
  • functionCategory, the domain the project argues in, such as therapy, alarm or protection.

Exchanges and flows. A FunctionalExchange is a transfer between two functions. It is written as a typed, named SysML flow from one function's out parameter to another's in parameter, so the edge is the exchange, and it carries the budgets and assurance attributes of the transfer. A FunctionalFlow is a reusable route through several responsibilities.

Behaviour. A StateMachine and its mode states are native SysML states. Transitions are native transitions inside them. A ModeConfiguration is the selection made at a variation choice point: which mode and elements are active in one arrangement. ActivityAction and ActivityFlow describe activity-style behaviour.

Obligations on behaviour. A BehaviorProperty is a behavioural obligation: an invariant, a transition rule, a temporal claim, an assumption, or a guarantee. It is a requirement def, so the design must meet it and a verification case can check it. Contract and TimingConstraint are requirement definitions of the same kind.

How it connects

Within the layer. Functions decompose by native nesting: a function owns its sub-functions. Exchanges connect function parameters with typed flows.

To other layers and disciplines:

  • Operational work is carried out by functions. An operative action, or a UI action in the implementation layer, performs a function. See Operational.
  • Functions are allocated to components with native allocate. A component function is allocated to exactly one. See Logical.
  • Requirements are satisfied by functions with native satisfy, and a BehaviorProperty is itself a requirement. See Requirements.
  • Verification names a function as the subject of a verification case. See Verification and validation.

In the running example

Detect temperature deviation is a high-criticality system function. The comment in the example makes the layering explicit: the function's safety and verification character are relationships to assurance elements, not tags on the function.

action fnDetectDeviation : SystemFunction {
    @MemoIdentity { :>> providedId = "TA-FN-001"; :>> label = "DetectTemperatureDeviation"; }
    attribute :>> criticality = CriticalityKind::high;
    // This function is owned by the functional architecture layer (its
    // package). Its safety and verification character are typed
    // relationships to assurance-owned elements, not tags on the function.

The full inventory

Generated from src/architecture/functional/.

Elements

Behavior

Element SysML kind What it is
FunctionalAction (abstract) action def Functional action definition specializing MemoAction.
StateMachine state def State machines and their mode states are SysML v2 states (behaviours), so they derive from the MemoState foundation, not the part-based MemoPart family. Transitions stay part-based (below) to keep their traceable safety attributes.…
ModeConfiguration part def A configuration is the concrete selection made at a variation choice point: it says which mode is active in one selectable arrangement. The reference is typed to the shared native state family so a consumer can navigate from the selected configuration to its governing mode.…
TransitionRecord metadata def Transitions are native SysML v2 transition usages inside the owning state — there is no part def Transition, and its transition keyword collision is why.…
BehaviorProperty requirement def Behavior property definition specializing MemoRequirementElement.
Contract requirement def Contract definition specializing MemoRequirementElement.
ActivityAction action def Activity action definition specializing FunctionalAction.
ActivityFlow action def Activity flow definition specializing MemoAction.
TimingConstraint requirement def Timing constraint definition specializing MemoRequirementElement.

Functions

Element SysML kind What it is
MemoFunction (abstract) action def Memo function definition specializing MemoAction.
SystemFunction action def A responsibility of the system as a whole. Allocation is optional: a system function that no single component owns is a normal intermediate state of the functional chain, not a defect.
ComponentFunction action def A responsibility of exactly one component. AllocatedTo names that component; CR-ONT-074 requires it. A component function that reaches no component is a responsibility nobody has accepted.
FunctionalFlow action def Functional flow definition specializing MemoAction.

Connections at a glance

Each arrow is one relationship, from its source end to its target end. A grey box belongs to another layer.

flowchart LR
  anyElement["any element"]:::other
  anyElement -->|FunctionalTransfer| anyElement
  classDef other fill:#eef1f4,stroke:#9aa7b2,color:#4a5a66

Relationships declared here

Relationship From To What it says
FunctionalExchange any element any element Typed relationship for functional exchange.
FunctionalTransfer any element any element The concrete exchange. A concrete flow def must declare its two ends, so this is the member of the family a model types its flows by; the ends are left untyped, as an exchange runs from an out parameter of one function to an in parameter of another (or between ports).

Relationships from elsewhere that reach this layer

None with an end typed in this layer.

Go deeper