The context of this discussion is the existing FLAME system for performing these tasks. The FLAME system works with single level electrical schematics, one schematic for each subsystem in the car, and with a set of functional labels for each subsystem. The functional labels can be used to interpret what is happening in a qualitative simulation of the circuit.
1. Introduction
The modern automobile has a complex electrical system. In order to manage the complexity of the system, the engineers break it into a hierarchy of subsystems, modules and components. Each of these subsystems, modules and components has a purpose in the overall car design, and so the idea of function can be associated with each of these items. For many of the subsystems, the functions are reusable from one subsystem design to the next. For many of the modules and components, the physical design as well as the function can be reused from one subsystem to the next.
This paper examines the issues involved in making maximum use of the hierarchy and the knowledge of function within the hierarchy, with minimum extra effort. This is done by extending the concept of functional labels introduced in the FLAME system, and used to interpret the result of a qualitative behavioral simulation.
This paper extends the idea of functional labels to work at different levels of abstraction in the car, with links between the different levels of function label. The status of this work is that it is somewhat speculative in nature. The work has not been implemented as yet. On the other hand, it is suitable as a workshop paper. It addresses issues of modularity and reusability of function, issues of general interest to the functional reasoning community, and could serve as a discussion starter at the workshop.
The general shape of the paper is as follows:
starts by considering some of the properties of the automotive domain. It outlines the kinds of application for which function is useful, and the kinds of natural hierarchy that already exist in the domain. It discusses how the concept of functional label can be extended to different levels within the natural hierarchy, and how to decide whether a function is occurring or not.
2. Reasoning About Automotive Systems
In the FLAME system we introduced the idea of the functional label as a symbol to provide an abstraction of some aspect of what a system does or is designed to do. Each functional label is associated with a particular part of the device being modeled, often this will be a system, module, or component. It also has a definition relating it to a particular system behaviour, usually a state, sequence of states, or the presence of a state change within the system being modeled. When this definition evaluates true then the function is active. Thus the set of functions which a system produces in any particular state can be calculated from the results of a physical or behavioural causal simulation. The set of labels deduced provides a very useful abstraction of system operation which we can utilize in a number of tasks, which are now briefly described. See papers [Price and Pugh], [Price et al. 97].
€FMEA - We can use qualitative analysis algorithms [Pugh and Snooke 96] to deduce electrical characteristics such as current flow and voltage from circuit schematics. The effect of various component faults can also be produced thus providing the raw data for an FMEA. To enable sensible interpretation of the effect of each fault however functional labels are used which provide a high level indication of system function or malfunction to the engineer.
€Sneak Circuit Analysis(SCA) - One possible class of faults occur when current takes an unexpected path - often in the opposite direction to the design intent - and causes unwanted activity in the circuit. In [Price, Snooke, Landry],[Price et al. 96] we find that by specifying for which switch states each function of a system is expected, and then simulating for every possible switch combination we can detect this additional unwanted functionality. In a hierarchical functional model we can relate all externally produced functions (including switch combinations, see section 3.2) and the system functions expected thus providing the information required for SCA. (see section 3.4)
€Diagnosis - It is possible to build a simple fault tree by rearranging the output of our FMEA by function rather than fault [Price and Taylor]. In this paper the fault 'tree' had 3 levels; system, failed function(s), and possible component failures including multiple faults. The use of a deeper function hierarchy should give us finer granularity in the fault tree. Diagnosis ability will therefore be improved by better partitioning of possible fault causes from a larger range of observable functions.
€Design Verification - We have been considering using state based behavioural description which when linked to a physical circuit simulation can be used to improve confidence in the design through redundancy in the model by ensuring the correlation between the two models. They are at quite different levels of abstraction reducing the probability of the same fault occurring in both. The inclusion of a functional model will provide better interpretation of any discrepancies between behavioural and structural models and possibly the future prospect of specifying the system by purely functional relationships to ensure all behaviours of a system actually fulfill the expected functions.
2.1 Natural Hierarchy
This work depends upon the organization of the models (schematics) into functional hierarchies. Though there are other many other possibilities, for instance a spatial organization grouping components according to position in the vehicle, the most common natural decomposition to use in automotive applications is roughly functional, producing a hierarchy including some of: product (vehicle), system, sub system, module, component. Each item in the hierarchy provides some function(s) to the next level in the hierarchy which will in general combine basic primitive functions to produce a more complex one. There is no restriction on the depth of the decomposition of the hierarchy, however a number of levels are commonly used which have significance with respect to the hierarchy in automotive electrical systems:
€Product - the top of the hierarchy, the vehicle in automotive terms
€System - provides all functions required to achieve a primary task of the product, eg.
lighting system, braking system, air conditioning system.
€Subsystem - a collection of closely related functions that contribute to a system function, only exists for the more complex systems. eg. the lighting system might be comprised of interior/courtesy lighting and exterior lighting
€Module/Device - Usually implies a spatially localised collection of components that performs one or more functions.
€Component - the lowest level of the hierarchy, linked directly to a physical object, eg. a lamp, wire, switch
Automotive manufacturers are moving towards the use of such a hierarchy within their electrical computer aided design (ECAD) tools. This is primarily driven by a need to simplify the drawings by reducing the amount of components on each sheet and is accomplished by replacing a group of components by a single symbol (which can be expanded to reveal its constituent parts, if required). Since it is advantageous that each grouping contains a relatively high number of components compared to the number of connections it is likely that the module combines all the functions of its constituent components into a few higher level functions which can produce signals (output) through a few connections. If the situation occurs where a module does nothing more than transfer the functions of its constituent parts to its surrounding context then no function abstractions need be attached and it will be treated simply as a graphical or structural decomposition unit.
Frequently used modules are stored in a library and can have their functional descriptions reused along with the other parts of the model (ie. symbol, internal structure, failure modes). At the highest levels of the hierarchy the functional description of a system may be reusable or partially reusable whereas its schematic may often be changed. At the lowest (component) level the entire model including function can (in the electrical domain at least) usually be reused, thus providing a component centered model obeying the no function in structure principle for the electrical simulation from which the functions of the model are deduced.
Clearly it is generally possible for a component to be used in a new way to implement a new function. In this case the new function must be added along with the aspect of behaviour which provides this function, for example we may have a transistor providing a switch function in one application but requiring an amplifier function in another. Conversely for a module providing several functions some implementation situations may not use some of the module functions. This situation can be overcome when we define the more abstract functions of higher level modules as will be discussed in section [relation between levels] below. For the electrical area it has not proved to be a significant problem however as low level components nearly always provide very few functions all of which contribute to the next level of device, and higher level modules are more specialized and are deliberately created/chosen to be used in systems for their particular (closely related) functions. At the sub system levels then there should always be a small set of related functions by definition since we chose the functional decomposition at a higher level.
Is worth noting that for other non electrical domains the function(s) of a 'component' may be quite varied, making it much more difficult to define all the possible functions of the component, and even harder to derive (automatically) which are significant in a given context. Taking the mechanical domain for example, our simple wire which only has the function of conducting electricity, can now also transmit force and produce sound (if plucked under tension. Such considerations remain to be investigated.
2.2 Refinement of function within one module
A device may require its own functional refinement before incorporating functions of a lower level device. For some systems of sufficient complexity, a clearer model (and simpler functional recognisers) are generated if several levels of functional abstraction are included. For example between the meta function label representing 'the system working' and the functional contribution of the various modules.
Allowing extra levels of refinement within the natural hierarchy is useful to the automotive domain for pragmatic reasons; parts of systems are sourced from outside suppliers, many modules are reused from previous products, and model building is limited by resources. It is therefore important that we allow use of whatever information is available for components and allow missing details to be supplemented in an easy and concise way at a high level for the following situations:
€A very limited natural hierarchy exists. In the past only a 'flat' schematic of the system has been available. We want to have a hierarchy of functions to the system, where no structural hierarchy exists.
€Sometimes a natural hierarchy does exist but functions have not been associated for low level components. This situation will exist in circuits which reuse a high proportion of components defined before the functional labelling system is available.
2.3 Observation of function for a module
Each device in the hierarchy has a number of functions associated with it and defined within the context of the device itself, so for instance the exterior lighting system may have functions sidelights, main beam, and dip beam, whereas a relay may have the function to switch power circuit or a lamp may have an illuminate function. Each function is defined as some part of the behaviour of a device that is sufficient for any item higher in the hierarchy (including ultimately a human user) to observe the expected effects of the function as occurring.
The behaviour of a device is deduced in two ways:
€An electrical simulation using the structure and physics of the device can allow prediction of non-normal behaviour but is specific to the domain and range of effects represented. For this model functions will be linked directly to quantities such as current or voltage produced by the simulation.
€The behaviour may be represented in the form of a state machine allowing physical aspects of the device from any domain to be represented. This model can only represent the expected operation of the device however, but is useful where a physical model for the characteristics of the device is unavailable. The functional model is associated with the state machine via a state, event, or sequence of states/events.
The linking expression for any function label is called the recogniser for the function and must evaluate to a boolean value although it can be arbitrarily complex involving many quantities or states as necessary.
3. Hierarchical Functional Labels
If we have a design composed of a hierarchy of functional blocks ranging from systems to components, each of which provides a set of functions and each of which is related to the others in a hierarchy of functional contribution then there is the possibility of refining the reasoning and explanation capabilities of our design and analysis tools using this additional information.
3.1 Reasoning Between Different Levels
It is useful to categorise contributing functions; those which contribute directly to the parent function so that if the component was removed the function could not be achieved - the function cannot be replaced by another function - usually these sub functions actually produce the observable effects of the parent function. Replaceable functions can (appear to) be replaced by the malfunctioning of another component for at least some situations. For example a short circuit could replace the function of a switch. The primary motivation for this distinction is as follows. If a function has a non replaceable contributing function which is expected to occur but it does not then the parent function will fail also. If the same occurs for a replaceable contributing function then the parent function will still be produced as long as all non replaceable contributing functions occur as expected.
Sub functions may contribute in different ways to a function:
€Necessary. The function cannot occur without the simultaneous existence of the contributing function. For example, main beam cannot happen without left headlamp bright.
€Combination. Only specific combinations of contributing functions can cause function to occur. Typical examples are one of several or at least one of several although more complex possibilities exist. This provides for modal meta functions which abstract several other functions, so either main beam or dipped beam or both simultaneously, cause the main lights function to occur.
€Sequence. When the function is an abstraction of an (ongoing or finite) process then the contributing functions are likely to have to occur in a specific sequence, possibly with time constraints for the function work. Think of the signal left function of turn signals for example. We avoid such dynamic processes currently by simplification, only dealing with sequences of stable situations.
For high level functions the recogniser expression may become complex since it represents abstract operation of the system - imagine defining the central locking function in terms of electrical currents in the actuators and door position switches - it would be much easier to define the high level functions in terms of the lower level ones. By using a hierarchy the problem now reduces to specifying that the central locking function is working if only one of the locking, vehicle_secure, unlocking, and vehicle_accessible functions is working correctly, with these in turn specified by various functions of the door sensors and actuators.
To allow higher level functions to be derived from its contributing functions, a recogniser function is created which interrogates the status of (non replaceable) lower level functions rather than values of physical quantities of the system. The recogniser which accesses the physical model should be equivalent to the one linking to lower level functions (if they were expanded) meaning that we could generate the physical link from the functional links if required. Figure 1 illustrates the simplest AND /OR relationships from which direct recognisers for function C could be derived as voltage1>0 AND current1=0, and functions A as (voltage1>0 AND current1=0) OR voltage2>0. For each function defined by a functional recogniser (rather than a behavioural or structural one) all sub functions used in the recogniser can be marked as non replaceable functions. If a non functional recogniser is used then any sub functions will need to be marked as replaceable for the correct identification of the functional hierarchy when failure operation of the device is considered (section 3.3).
When the functional model is only being utilized to abstract function from the simulation results of other epistemological models, it does not require externally produced functions to be specified in the functional model. We use either the events specified at the system level of a state based behaviour (example in figure 3), or if this is not available, the external states associated to structural components which are especially defined to always be external at the top most (ie product) level. Following simulation the status of all functions, including externally produced ones can be derived via the function recognisers.
3.3 Recognising function in a faulty system
When a simulation is run for a system containing a failed component, the situation often arises where a high level function appears to be achieved although the contributing functions are in fact different. In figure 2 we may find (for correct operation) when function B is active then so should be functions A, C, D, E, F however when a fault causes E to fail then only B, D, A become active. This could be misleading since although A is active according to its definition it is now in a different mode and is therefore not performing as expected. To resolve such situations we introduce the idea of a partially achieved function. A function is partially achieved when the set of sub functions are not those expected although the functional recogniser still evaluates true. Any sub function itself marked as partially achieved will be treated as being achieved but the parent will automatically be made partial (if not false !). After each externally produced function is applied to the system the contributing non replaceable functions are checked and if any are missing, or partially achieved, or any extra functions exist, then the higher level function is also marked as being partially achieved.
Notice that partial operation means that a function is operating, but not in the mode expected rather than meaning a failure of a required sub function. In an automotive example the partial failure of main lights may mean that we only get dip beam when main beam was expected. It could not mean the left hand lamp is not working because this would cause a total failure of the main and dipped functions since both left lamp and right lamp are required to fulfill these functions.
The status of replaceable functions clearly has no effect on the status of any parent function, although when an inconsistency exists between actual and expected replaceable functions this will often manifest itself in the incorrect operation of one or more non-replaceable functions. This causal relation is not encoded in the functional hierarchy but is produced in the physical simulation and detected through the relevant recogniser hierarchy.
3.4 Building a predicting functional model
The hierarchical functional label scheme developed so far has no links between the status of externally produced sub functions and the mode of other (combinatorial or sequential) meta functions. When this information is added (possibly by means of conditions associated to each specifying any necessary externally produced functions) the function label hierarchy could be traversed from most to least abstract in order to predict the expected functions for each set of external functions.
Referring to figure 2 as an example the required contributing function could be specified by making C dependent on B and D dependent on NOT(B). We would then get either A, B, C or A, D as the two expected function hierarchies for the device dependent on the external function B.
This model can (as for a state based behaviour model) only predict the functions of a device for its correct operation. However the ability to produce a correct and complete functional specification of a system for all external function combinations (switch settings in FLAME sneak circuit) may still prove useful as it is the key information required for detection of sneak paths in circuits.
4. An Example: The exterior lighting circuit
The following section describes part of an automotive lighting system to illustrate the use of the functional label hierarchy . This circuit has 3 levels of device hierarchy and for brevity we only include a selection of the components. Each level provides the functions indicated:
€the lighting system level has functions sidelights, main_lights, main_beam, dip_beam
€the module level has -
€lighting switch: path1 (turn on side lights, turn off main lights)
€lighting switch: no functions (switch off lights)
€lighting switch: path2 (turn on main lights)
€dip switch: make circuit (dip lights)
€dip switch: no functions (full beam lights)
The following table itemizes every possible functional state of the system. For n external functions there are 2n possible combinations:
| dip switch: make circuit | light switch: path1 | light switch: path2 | expected (light system) functions | comment |
| none | ||||
| active | main beam, sidelights | |||
| active | sidelights | |||
| active | active | switch failure only | ||
| active | none | not expected | ||
| active | active | dip beam, sidelights | ||
| active | active | sidelights | not expected | |
| active | active | active | dip beam, sidelights | switch failure only |
Some of the combinations are excluded from the normal device function. In this example the main switch cannot be in both positions simultaneously. The weakest form of excluded combinations are those which do not form part of the normal external operation of the device although these are physically possible (dipping the lights when only the sidelights are on) and we may wish to test these during design verification tasks, and certainly for sneak circuit analysis.
From all of the possible externally produced functions how do we decide which combinations to test since it may not be possible to simulate all for a real system? The answer depends to some extent on which analysis task the model is being used for. Two approaches have been considered:
€One approach which we used in FLAME was simply to ask the engineer to provide a sequence of events to 'exercise' the system. Following each event a new combination of external functions will be created. In this way any required functional states of the system can be produced if enough events are triggered.
€Use the events specified by a behavioural model. This approach provides a slightly more structured way of generating events by reducing the possibilities from each system state as in figure 3. The use of state machines is being considered where we need to supplement structural models such as for the operation of devices such as ECUs as well as for general behavioural description of components. We will not consider the details here since this paper is concerned with function.
5. Summary
To some extent, this paper discusses the turning of a full circle. Our original use of functional modelling for FMEA [Hunt, Pugh, Price] employed a functional scheme not unlike that of many other researchers in the FR community, e.g. [Sticklen et al.]. Two of the problems with this scheme were the maintenance of the models by engineers, and the linking between the functional models and the structural models also employed.
In [Price and Pugh], we describe the benefits of a much simpler scheme, where the functional level consists only of functional labels, and most of the work is done by qualitative reasoning. Even in that scheme, the functional labels are vital, because they provide the ability to interpret the results of the qualitative reasoning. The practical utility of such a scheme has been proven by industrial deployment of the resulting systems.
In this paper, we explore the possibilities and benefits of a more complex arrangement of functions, nearer to the hierarchical arrangement of functions and behaviours within FR. One of the main differences from FR is the way in which different levels are linked together. We have preserved the idea of functional labels, but extended the ways in which functional labels can be linked to lower levels. In [Price and Pugh], they can only be linked to electrical circuit behaviour at the lower level. In this paper, we propose to link them to either electrical circuit behaviour or to lower level functional labels. This allows a hierarchy of functions to be defined, while preserving the advantages of functional labels (modularity, high level of reuse, ease of use for interpretation).
Hierarchies of functional labels provide the potential for more powerful reasoning about electrical circuits. It remains to be seen whether the benefits of such reasoning outweigh the additional burden of identifying the hierarchy and defining links between levels in the hierarchy. Much of the necessary information occurs in the natural hierarchy generated during automotive design, and so we believe the additional work of building the kind of hierarchy depicted in this paper will prove worth the engineer's effort.
Acknowledgements
This work has been carried out on the UK EPSRC funded project "Aquavit" GR/L20542, with the cooperation of Jaguar Cars Ltd, Ford Motor Company Ltd, Integral Solutions Ltd and Viewlogic Systems Ltd.
References
[Hunt, Pugh, Price] J. E. Hunt, D. R. Pugh and C. J. Price, Failure Mode Effects Analysis: A Practical Application of Functional Modelling, Applied Artificial Intelligence, vol 9(1), pp33-44, 1995.
[Lee and Ormsby 93] Lee, M. and Ormsby, A. 1993. Qualitative Modelling of the Effects of Electrical Circuit Faults. Artificial Intelligence in Engineering vol. 8, 293-300.
[Price and Taylor] C. J. Price and N. S. Taylor, Multiple Fault Diagnosis Using FMEA, to appear in Proceedings of IAAI-97, Providence, Rhode Island, July 1997.
[Price and Pugh] C. J. Price, D. R. Pugh, Interpreting Simulation with Functional Labels, 10th International Workshop on Qualitative Reasoning, Stanford Sierra Camp, May 1996.
[Price, Snooke, Landry] C. J. Price, N. Snooke and J. Landry, Automated Sneak Identification, Engineering Applications of Artificial Intelligence, volume 9(4), pp423-427, 1996.
[Price et al. 96] C. J. Price, N. Snooke, J. Landry and M. S. Wilson, Identifying Sneak Paths through Function, AAAI-96 Workshop on Modelling and Reasoning with Function, pp16-21, Portland, Oregon, August 1996.
[Price et al. 97] C. J. Price, N. Snooke, D. R. Pugh, J. E. Hunt, M. S. Wilson, Combining Functional and Structural Reasoning for Safety Analysis of Electrical Designs, to appear in Knowledge Engineering Review, 1997.
[Pugh and Snooke 96] Pugh, D. and Snooke, N. Dynamic Analysis of Qualitative Circuits. In Proceedings of Annual Reliability and Maintainability Symposium, 37-42, IEEE Press, 1996.
[Sticklen et al.] J. Sticklen, B. Chandrasekaran and W. E. Bond, Distributed causal reasoning, Knowledge Acquisition 1(2), pp139-162, Academic Press, June 1989.