Skip to content

Functional Analysis

The functional layer answers what the system must do without saying how. This separation is what lets one functional architecture survive a technology change — and what stops every function from silently becoming software. A SystemFunction may be realized by human action, mechanics, electronics, software, or a combination; the allocation decision is explicit and comes later.

Keep five meanings distinct

The vocabulary here earns its size by preventing one recurring confusion — work, responsibility, behavior, organization, and path are different claims:

Element Meaning
OperationalActivity Work performed in the operational world (by people)
SystemFunction Technology-independent responsibility of the system
FunctionalFlow Reusable organization of functions; each step is an action nested in the flow that subsets the function it performs
MemoScenario[scenarioKind=functional] A selected path through a functional flow

FunctionalExchange is a typed transfer (measurement, command, alarm, …) between functions. It is a flow def, and an exchange is a named flow from one function's out parameter to another's in, carrying its latency, staleness and integrity attributes in its body:

flow lfFlowCommand : FunctionalExchange
    from fnManageInfusion.flowCommandOut to fnCommandPump.flowCommandIn {
    attribute :>> latencyBudgetMs = 20.0;
}

The flow is the exchange — there is no separate element beside it — and its qualified name is what allocate lfFlowCommand to exFlowCommand; names. An action flow may call a function, but it is diagram behaviour rather than another functional-architecture element.

Core relationships

Write (native SysML) Reads as
dependency This function supports that operational work, without performing it
perform This action, flow, or scenario carries out that function
nesting This function or flow is made of these sub-functions and steps
#refinement dependency <realizing> to <realized> This element realises that one
allocate This function is the responsibility of that logical component

Function-centered traceability

Functions provide a useful traceability anchor: requirements and risk controls constrain them, architecture elements take responsibility for them, and verification cases produce evidence about them. The source model remains the authority for the exact relationship types and their endpoints.

Example thread

flowchart LR
    Bolus[OperationalActivity: request bolus] --> Chain[FunctionalFlow: patient bolus]
    Chain --> Sense[SystemFunction: acquire sensors]
    Chain --> Limit[SystemFunction: enforce limits]
    Chain --> Command[SystemFunction: command pump]
    Limit --> Logical[LogicalComponent: monitor channel]

In the GPCA example, gpca_behavior_subsystems.sysml defines the functions and exchanges, and gpca_system.sysml organizes them into flows whose steps carry typed references to functions and exchanged items — follow FCS-001 through FCS-005 for the complete bolus path.

Continue the story

Next, read Requirements and Architecture. It connects the claims that constrain a function to the logical and implemented parts responsible for it.