FRAM Models for Conformance
Standards, such as ISO/IEC or BS EN 61508 are ubiquitous in their application, but confusing (and often confused) in their interpretation. 61508 is not alone in this. Not by a long shot. Constituted by seven (largely) text based parts, 61508 is not an easy standard to digest, never mind instantiate correctly.
In both my professional, and my academic careers, I have both used, and created patterns to breakdown complex tomes into clear manageable activities, and process steps – replete with consideration of the quality attributes required of each activity / step. I want to share a series of these patterns with you. Patterns you can use to:
- Plan for conformance
- Assess conformance
- Plan resource profiles, and even
- Manage Training Needs Analyses, etc.
The modelling symbology I use is predicated on the Functional Resonance Analysis Method (FRAM). Whilst I find using FRAM eminently simple and intuitive, I’m neither a FRAM-zealot, nor disciple – so please feel free to use any methodology, symbology or ontology you so desire. So what is FRAM?
The Functional Resonance Analysis Method (FRAM) was originally designed with the aim of assessing the safety of a system in terms of what is needed in performance terms – in order that “everything goes right” [1], and is a useful tool for modelling complex, socio-technical systems. The original FRAM symbology was designed to simplistically represent and assess activities that occur sequentially / chronologically in a process. An activity is depicted by a hexagon, and the circles on the edges of the hexagon denote the required attributes of an activity or artefact (more on that soon).
These attributes are referred to as ‘aspects’, and are used to link activities and artefacts together as shown in the example on retrieving cash from an ATM in the figure below (taken from [1]).
Whilst retaining most of the structure of the original FRAM, the version used for these patterns has been modified to represent the activities required by IEC/BS EN 61508 part One Lifecycle (see next figure taken from [2]), and was carried out by undertaking a line-by-line review of the standard.
Each hexagon represents an activity required by the standard, and each triangle represents an artefact which is produced and / or consumed by an activity (such as a resource to carry out the task, or a documentary artefact which controls an activity being undertaken).
The activities and artefacts are linked together to denote the artefact’s role as either:
- Inputs to an activity
- Outputs produced by an activity
- The time by which an activity should commence / complete
- Methods / techniques by which an activity is completed
- Controls which constrain/inform the way an activity should be undertaken, OR
- Resources expended.
Each artefact is also annotated with the quality attributes required of the artefact:
- The time the artefact should be produced or delivered to enable an activity to commence
- Any quality criteria required of an artefact (i.e. the skills and experience of a Resource, or the format of a report), and
- Whether the artefact exists, or whether another activity should be modelled to create it.
In certain circumstances, it is neither meaningful nor helpful to consider the aspects of an artefact. An example of this is when considering ‘Time’. Whilst time needs to be stated (e.g. phase / date etc.), it is not meaningful to define any quality attributes of time. In such cases, a simple free-text box is used.
Well, that was a very quick whistle-stop tour of FRAM, I hope I’ve made it easy to understand, but if you would like to know more about FRAM, see [1], and it you want more information on how I have modified it for use in Process Patterns, please take a read of [2] .
And without further ado…I present to you the patterns for Part One of 61508. Just get them downloaded and use to your hearts content. All I ask is that you formally recognise them as my creation. Enjoy!
Parts Two and Three coming soon!
References
[1] Erik Hollnagel. FRAM: The Functional Resonance Analysis Method. Ashgate, Dorchester, 2012.
[2] Matt Osborne. Identifying Effective Improvements to Software Safety Practice, University of York, 2025.
