Thomas Brown Controls
Services

Functional design that turns requirements into something engineers can build and test.

TBC develops Functional Design Specifications, control philosophies, cause-and-effect matrices and interface information that define how a control system should operate before software, drawings and testing are committed.

Control philosophy

From requirement to testable control philosophy

A successful control system needs more than a list of I/O points. Operating modes, sequences, permissives, interlocks, failure responses and equipment interfaces need to be agreed in a form that engineers can review, implement and prove.

  • Client requirements and specifications translated into defined operating behaviour
  • Modes, equipment states and sequence steps written before implementation
  • Interfaces and control responsibilities agreed between systems
  • Acceptance criteria carried forward into FAT, SAT and commissioning
RequirementsWhat the system must achieve, including constraints and operating assumptions.
SequencesWhat happens next, under which conditions and which equipment has authority.
InterfacesSignals, responsibilities and dependencies between PLC, SCADA, switchgear and packages.
AcceptanceClear statements that can be turned into practical FAT and SAT test cases.
Engineering documents

Typical functional-design deliverables

The document set is selected to suit the project. The aim is to remove ambiguity at the points where software, electrical design, vendor interfaces and testing depend on the same decision.

  • Functional Design Specifications and control philosophies
  • Cause-and-effect matrices and sequence descriptions
  • I/O, interface and equipment schedules
  • Software Design Specifications, architecture and test criteria where required
FDSModes, sequences, automatic actions, alarms, trips and failure responses described in reviewable form.
Cause & effectInputs or events tied clearly to required system responses and reset conditions.
SchedulesI/O, equipment and interface information used consistently by hardware and software teams.
SDS / architectureImplementation detail added where the project needs a separate software or network design layer.
Interfaces & responsibilities

Control authority made explicit before systems are connected

Many project problems sit between packages rather than inside one controller. Functional design identifies which system owns a decision, which signals are exchanged and what happens when the expected information is missing.

  • PLC and SCADA commands, status, alarms and operator authority
  • Switchgear, generator-controller and protection-system responsibilities
  • BMS, packaged equipment and process-system interfaces
  • Metering, PV, BESS and other third-party control boundaries
Control authorityWhich system is allowed to command equipment in each operating mode.
Signal exchangeCommands, permissives, availability, status and failure information defined at the boundary.
Failure behaviourExpected response when equipment, communications or supporting systems become unavailable.
NamingEquipment and signal references kept consistent between documents, software and drawings.
Designed to be tested

Requirements should lead directly into the test plan

A functional requirement is only useful if the people implementing and testing it can agree what successful operation looks like. The design should make normal, abnormal and recovery scenarios clear enough to prove.

  • FAT test cases traced to approved functional requirements
  • SAT scenarios covering installed equipment and site interfaces
  • Failure cases for unavailable equipment, lost signals and abnormal conditions
  • Acceptance criteria that distinguish expected behaviour from defects
Normal operationExpected sequences, transitions and operator actions defined before testing starts.
Abnormal operationTrips, unavailable permissives and degraded modes given an agreed response.
RecoveryReset, restoration and return-to-service behaviour described rather than assumed.
TraceabilityTest evidence can be tied back to the requirement and the revision that was approved.
Related engineering

Functional design provides the baseline for the disciplines that follow.

Once the operating philosophy and interfaces are agreed, the PLC, SCADA, electrical design and test work can all be developed against the same definition rather than interpreting the requirement separately.

PLC engineeringSoftware architecture and logic developed from the agreed modes, sequences and interfaces.
Electrical & control designSchematics, I/O and schedules produced against the same equipment and signal definitions.
FAT, SAT & commissioningOperating and failure scenarios converted into structured test procedures and evidence.
Control systems integrationAgreed functions and interfaces carried across PLC, SCADA, electrical systems and third-party equipment.

Need the control philosophy defined before software or drawings move further?

Send the available specification, cause-and-effect, equipment information or current design and TBC can structure the functional requirements and interfaces into a testable engineering baseline.

Discuss a project