1 / 77

Distributed Fault Detection for untimed and for timed Petri nets

Distributed Fault Detection for untimed and for timed Petri nets. René Boel, SYSTeMS Group, Ghent University with thanks to: G. Jiroveanu, G. Stremersch, B. Bordbar. Outline. problem formulation and models centralised diagnosers via backward search

Download Presentation

Distributed Fault Detection for untimed and for timed Petri nets

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Distributed Fault Detectionfor untimed and for timed Petri nets René Boel, SYSTeMS Group, Ghent University with thanks to: G. Jiroveanu, G. Stremersch, B. Bordbar

  2. Outline • problem formulation and models • centralised diagnosers via backward search • distributed diagnosis for interacting Petri nets • fault detection for timed Petri nets • probabilistic fault diagnosis

  3. adaptive supervisory control? improve behaviour of large plants consisting of many interacting components controlled by disabling events in order to guarantee that certain specifications are always satisfied requires on-line estimation of current mode of operation of plant

  4. feedback control paradigm observed output plant state estimator and fault detector controlled input feedback law

  5. distributed feedback control paradigm plant plant plant plant fault detector fault detector fault detector fault detector feedback law feedback law feedback law feedback law

  6. distributed fault detection for large discrete event systems • locally observable events at fault detection agenti (possibly small) subset of all events happening in planti • assume: all observable events are always seen immediately by local fault detection (FD) agent, with their exact occurrence time (global clock)

  7. distributed fault detection for large discrete event systems • Can cooperation between local fault detection agents guarantee same quality of fault detection as would be achievable by a centralized fault detection agent that • observes all observable events (planti, i = 1,...,I) • knows model of complete plant • what is minimal information to be exchanged between FD agents for achieving same performance as centralized FD?

  8. distributed state estimation for discrete event models model includes unobservable events that cause deterioration of plant behavior, i.e. faults • each local fault detection agent implements local FD algorithm, in order to adapt supervisor's reaction to current mode of operation of plant • local agent uses sequence of observable events generated locally

  9. distributed state estimation for discrete event models one fault detection (FD) agent per component limited communication between local FD agents allows performance as good as centralized FD agent that: would see all observable events, would know global model

  10. distributed observers • distributed implementation reduces on-line computational complexity of FD agents • distributed implementation makes fault detection more robust against communication errors that centralized FD ...provided local FD agents provide overestimate of set of possible faults

  11. distributed observers distributed implementation of FD agents makes fault detection less sensitive to errors in knowledge about model especially knowledge of distant components often outdated when components change often

  12. distributed observers • but design more complicated because • local FD agents must understand effects of interaction between components • communication strategy between local FD agents must be designed

  13. Petri net model common places may be unobservable parts of physical network interactions via common places - no common transitions assume at least one observable event in cycle covering more than one component only very few transitions generate (locally) observable signal

  14. interaction of Petri net components • described by token passing via common places • token entering boundary place enables events to happen only once in neighboring components

  15. interaction of Petri net components described by token passing via common places token entering boundary place enables events to happen only once in neighboring components

  16. interaction of Petri net components tight interaction between components local FD agenti may not know initial marking of places in planti forward explanations not possible for generation of allowed trajectories explaining observations

  17. backward explanation • generate all trajectories that • are compatible with observations up to present time • are compatible with plant model • starting from most recently observed execution of transition t and recursively moving upward to its input places °t, its input transitions °(°t), and so on until possible previous marking is obtained

  18. Petri net: example for explaining backward recursion places  P transitions  Τ Pre arc Post arc t13 token place with 2 tokens

  19. decompose Petri net in 2 components that interact via places p5, p9 each component contains one fault transition, resp. t1, t8 t13 each component contains one observable transition, resp. t6, t10 Algiers, 5/5/07 VECOS'07

  20. observer design for one single component behaviour: Petri net model generates sequence of events observation: only some of the events are observed by control agent model: set T of transitions partitioned in observable transitions t  To and unobservable transitions t  Tu

  21. Petri net: compositional modelling Large plants can be represented by several Petri net components, interacting with each other by unobservably exchanging tokens via common places component 1 component 2

  22. Petri net: compositional modelling set P of places of Petri net model consists of • "local places" in each component i • for component i: "input places PIN,i,j that have input transitions (Pre) in component j and output transitions (Post) in component i • for component i: "output places POUT,i,j that have output transitions (Pre) in component j and input transitions (Post) in component i decomposition not constrained by limitations on sensors

  23. Petri net: compositional modelling To avoid unnecessary complications in analysis: assume Petri net bounded, i.e. all reachable markings have bounded number of tokens in each place Problematic assumption: boundedness depends on the global structure of the Petri net, cannot be verified locally!

  24. Petri net: compositional modelling fault detection agenti for componenti only observes local observable events agent1 observes each occurrence of t6, at clock times (t6)n agent2 observes each occurrence of t10 at clock times (t6)n component 1 component 2

  25. computational complexity combining two components of similar size leads to much more complicated behaviour number of possible traces of combination of two components is much larger than twice the size of the behaviour of each component separately! exponential explosion of computational complexity!

  26. Outline • problem formulation and models • why distributed on-line state estimation? • backward generation of explanations • distributed diagnosis • extensions to timed DES models • open questions and conclusions

  27. example only observable event: t10 fault event: t8 p5 p8 t8 t9 p6 if only p8 is marked initially then only normal behaviour is trace {t12} and empty trace while possible faulty behaviour contains all prefixes of {t8, t10, t11} including empty trace p11 t10 p7 t13 t12 t11 p9

  28. prefix set of all prefixes of {t8, t10, t11} = , {t8}, {t8, t10}, {t8, t10, t11} since untimed model does not specify any upper bound on time delays for events the model can never guarantee that an enabled event will have happened

  29. example only observable event: t10 fault event: t8 p5 p8 t8 t9 p6 if only p5 is marked initially then normal behaviour includes all prefixes of the trace {t9, t13, t10, t11} where moreover t13 can also occur after t10 and after t11 p11 t10 p7 t13 t12 t11 p9

  30. unfolding of Petri net • set of all prefixes and permissible reorderings of the trace {t9, t13, t10, t11} = , {t9}, {t9, t13}, {t9, t10}, {t9, t13, t10}, {t9, t10, t13}, {t9, t10, t11}, {t9, t13, t10, t11}, {t9, t10, t13, t11}, {t9, t10, t11, t13} • described by unfolding of the net, obtained by • by "opening all cycles" and • by "copying all places with more than 1 input transition"

  31. unfolding of Petri net • example does not contain cycles • place p6 and place p9 must be replaced by 2, resp. 3 copies of the place p5 p8 t8 t9 p6,1 p6,2 p11 t10,1 t10,2 p7,1 t13 p7,2 t12 t11,1 t11,2 p9,1 p9,4 p9,2 p9,3

  32. unfolding of Petri net after unfolding a Petri net each token is generated by a uniquely defined sequence of events problem: how to make an unfolding finite? It is possible to obtain a finite unfolding of a Petri net so that "same behaviour" is generated (taking into account that repeating a cycle infinitely often does not generate new states)

  33. forward analysis via unfolding • if initial marking is known then one can enumerate all possible traces that end with an observable event occurrence • and select as possible explanations of the observed events only those traces that contain the observed events in correct order • using unfoldings avoids need for enumerating all possible orderings of unobservable events

  34. forward analysis via unfolding but requirement that all initial markings are known (or an upper bound on these markings) is not acceptable for distributed fault detection since componenti does not know how many tokens componentj puts in input places PIN,i,j and when it puts these tokens there

  35. Outline problem formulation and models why distributed on-line state estimation? centralised diagnosers distributed diagnosis extensions to timed DES models open questions and conclusions

  36. backward search • can avoid this difficulty • finding minimal explanations via backward search determines where tokens should be available and by what time they must be in that place

  37. example: backward search observe: t10 at time (t10) p5 p8 t8 t9 p6 token must have arrived in p6 before (t10) p11 t10 p7 t13 t12 either fault t8 or unobservable event t9 must have fired before (t10) t11 p9

  38. example: backward search observe: t10 at time (t10) p5 p8 t8 t9 p6 token must be present in p6 before (t10) or have been sent to p5 by neighboring component before (t10) p11 t10 p7 t13 t12 t11 p9

  39. example: backward search FD agent2 knows token was present in p8 prior to (t10) and hence it can determine that fault t8 may have occurred but determining whether fault t8 occurred for sure requires information from neighboring component that it can put token in p5 before (t10) p5 p8 t8 t9 p6 p11 t10 p7 t13 t12 t11 p9

  40. example: backward search in order to determine whether explanations (t9 t10) is also possible FD agent2 must ask niehgboring FD agent1if it is possible that a token arrived in p5 before (t10) note that FD agent2 does not have to know model of plant1 except for fact that p5 is common place p5 p8 t8 t9 p6 p11 t10 p7 t13 t12 t11 p9

  41. example: backward search • possibility of token in p5 • depends on whether • agent1 knows that 2 • tokens in p0 present • before (t10) • if so then • irrespective of how • many times t6 has • been observed by • FD agent1 a token • could may reach p5 • prior to (t10) t13 Algiers, 5/5/07 VECOS'07

  42. example: backward search agent1 responds that it is possible that p5 became marked before time (t10) from this response FD agent2 concludes that the fault t8 may or may not have occurred t13 Algiers, 5/5/07 VECOS'07

  43. example: backward search Note that a central observer knowing both models and seeing all observations also would not be able to draw an unambiguous conclusion t13 Algiers, 5/5/07 VECOS'07

  44. example: backward search FD agent1 will return the same response if only 1 token is in p0 but t6 has not been observed yet, and the conclusion of FD agent2 will be the same however FD agent1 will know then that the token in p0 can no longer be used for future explanations t13 Algiers, 5/5/07 VECOS'07

  45. example: backward search • if only 1 token were • present in p0 prior to (t10) and FD agent1 has observed the occurrence of t6 • prior to (t10) then the token in p5 can only occur via (t0, t3, t6) • which requires a token in p9 prior to (t10) t13 Algiers, 5/5/07 VECOS'07

  46. example: backward search but then ... agent1 must return the question to agent2 and ask it is possible that p9 has received a token prior to (t10) FD agent2 will answer that this is indeed possible, and will receive a positive answer from FD agent1 t13 Algiers, 5/5/07 VECOS'07

  47. example: backward search moreover FD agent2 knows that in that case the only explanation of t10 occurring at (t10) is the sequence of events (t9,t10) then FD agent2 can deduce that the fault t8 has not occurred t13 Algiers, 5/5/07 VECOS'07

  48. distributed fault diagnosis via backward search • method described in simple example can be applied for all compositions of Petri nets interacting via common places • using general algorithm for generating minimal explanations (backward unfolding) • at random times any FD agent can initiate communication round that is assumed to reach a conclusion instantaneously (before any other fault or observable event can occur)

  49. local explanation = ordered sequence of local unobservable and observable events, so that • ordering of observable events corresponds to observations • uppermost transition of local explanation is either a place that is known locally to be marked initially, or a place where a token can enter the local component from a neighbouring component

  50. fault diagnosis • Relaxed diagnosis goal! • Enumerate only the minimal traces containing sequences of events that must have happened for OBSito be allowable • do not expand minimal traces, i.e. do not include transitions that do not lead to satisfaction of constraints necessary for occurrence of observable event

More Related