Architecting and Functional Analysis

In Sec. B4.3 we introduced the concept of functionality and the concept of the functional domain. In particular, we discussed the existence of a transition from the functional domain into the physical domain that is, a transition from an abstract domain in which there are only requirements on services (essentially activities) to a domain in which these requirements are reflected onto an architecture, i.e. a set of interacting physical elements. 

Another way to look at this is to first consider how some systems, made up of relatively simple elements, can have properties that are complex and, at least initially, unexpected. A small example of this is how a few capacitors and inductors can give rise to a band-pass filter. So, if we had initially required the properties of a (passive) band-pass filter, how would we have deduced that the elements we needed should have the properties of capacitors and inductors This problem is the converse to the problem, discussed in Sec. A4.1, of predicting the emergent properties from the properties of the elements. 

This immediate focus on the physical domain is also evident if we look at some of the defining documentation on systems engineering we see that almost all of the material relates to operations on physical entities, as exemplified e.g. by the List of Requirements in EIA-632. And indeed, that same standard defines a system as an aggregation of end products and enabling products to achieve a given purpose so it is clearly focused entirely on the physical domain. But how do we know that we have considered all possible architectures And how do we prove that a particular one is the optimal one There are many aspects to these issues, such as previous experience and boundary conditions, but it is certainly 

---

Through the activities of architecting and functional analysis, described in the previous chapter, we identify the functions that the plant must have in order to meet the functional requirements, and we express this in the form of a system of functional elements. These are the primary elements. However, we now need to realise that the functions we, as engineers, determine will be required to provide the service will generally include a number of functions that are not directly involved in providing the service, and in conformance with normal practice we subdivide the system of primary functional elements into three subsystems,... 

The aim of this brick is to support local FMEA (Failure Mode and Effects Analysis) on the model elementary components and to generate automatically Fault Trees. Using a system functional design or its physical architecture model by any interoperability mean (lOS), the user performs a local analysis inside Safety Architect, by linking failure modes of the outputs of the components to the failure modes identified on the component inputs. During the local analysis, the user also analyses the effects of internal failures of the component on its outputs. 

---