fig1 a shows a networked computer system connected to apparatus 5 in accordance with the principles of the present invention . three computer nodes 1 , 2 , and 3 are shown connected to a computer network n . the network n is interconnected with other networks ( n1 , n2 , n3 , n4 ) via communication nodes , a bridge node 17 and a router node 18 . the phrase &# 34 ; network of computer nodes &# 34 ; as used herein and in the claims will be understood to refer to both a network which only includes computer nodes and to a network which further includes communication nodes . each computer node may also be connected to peripherals such as 1a , 2a , and 3a - 3c . moreover , two or more computer nodes may be connected via an interface 4 . each computer node may generate one or more signals on network n , or through other means , corresponding to symptoms in the system . examples of symptoms for which signals may be generated could include power failure , peripheral failure , temperature limit exceeded , network interface error , adding a new address on the network , or the like . of course , any conceivable type of symptom which can be detected could be generated . through the use of apparatus 5 , the networked computer system may be monitored and problems reported based on observed symptoms . apparatus 5 , which may be implemented on a computer of any of various types , is connected to network n , although it may be connected to the system through any other means such as direct i / o connections to the various computer nodes or by a wireless link . apparatus 5 includes event detector 6 which receives and monitors events representing symptoms and determines that a particular event has occurred ( for example , a power failure message received from one of the computer nodes ). these events , generated by computer nodes 1 - 3 , may be transmitted by any suitable means , such as sending data packets over an ethernet ™ which are received by apparatus 5 . apparatus 5 also includes event decoder 10 which receives detected events from event detector 6 and , by way of codebook 11 , determines one or more &# 34 ; best fit &# 34 ; problems corresponding to the detected event . codebook 11 may be stored in a computer storage device such as a disk file or in computer memory , and event decoder 10 comprises means for reading values from codebook 11 . after determining the best fit problem , event decoder 10 causes report generator 13 to generate a report 14 which provides an indication of a problem for which corrective action might be taken . report 14 may be generated in any of various forms such as a message sent to computer systems responsible for automated handling of problems , a record of the problem logged in a storage device ( such as a file or a database ), a computer - generated printout , a computer display 15 , data sent to a software client 16 , indicators on a control panel , or the like . additionally , the reported information may be displayed in alphanumeric or graphical form , or it may comprise a signal containing the reported information which may be further transmitted to another location . codebook 11 may be generated by codebook generator 12 in accordance with the principles of the invention as outlined in more detail herein . the term &# 34 ; file &# 34 ; as used herein will be understood to include any computer - accessible storage including memory , disk , or the like . a causality matrix 9 contains a mapping of system symptoms to likely problems , preferably with probabilities corresponding to each mapping . thus , for example , the likelihood that a reported power failure in one of the computer nodes is the result of a blown fuse might be assigned a probability of 0 . 25 . although causality matrix 9 may be generated by manual means , it may be generated automatically using event capture 7 and event validation 8 based on events which are observed over a period of time , or it may be generated by interpreting a formal specification of an event model and an event propagation model in a specific domain , both described in more detail herein . for example , the latter may be performed by generating a causality matrix by compiling a formal language that specifies the event and propagation model into methods and data structures that interpret the models in a specific configuration . this process is described in more detail herein . event capture 7 and event validation 8 may be controlled interactively by way of control means c1 and c2 , respectively , such as through operator input using a suitable command stream . fig2 b illustrates a method for employing the principles of the present invention in various embodiments . beginning with step 20 , a causality matrix is created , the matrix comprising a mapping of observable symptoms in the system to likely problems corresponding thereto . at step 21 , the causality matrix is made &# 34 ; well - formed &# 34 ; by eliminating redundant information in rows and columns . at step 22 , an optimal codebook is generated which further reduces the amount of information in the matrix ; this optimal codebook may be tailored for a particular level of error tolerance or symptom loss as described in more detail herein . at step 23 , observable symptoms generated by the system are monitored , and at step 24 these monitored symptoms are decoded into problems , preferably using a mismatch measure to determine their closeness to the observable symptoms contained in the optimized codebook . at step 25 , a report is generated corresponding to the one or more likely problems decoded from the optimized codebook . the process may then either repeat at step 23 , or the generated report can be fed to either step 20 or step 22 to refine the causality matrix or the codebook respectively . fig1 c shows details of one possible embodiment for event decoder 10 . codebook 30 , which represents the same element as codebook 11 of fig1 a , contains an illustrative set of numerical probability values shown as 30m . event sequencer 10b receives events such as vectors of symptoms and , for each such vector , retrieves values from codebook 30 . mismatch measuring circuit 10a is used by event sequencer 10b to compare symptom vectors with values contained in codebook 30 . the &# 34 ; best fit &# 34 ; matches between values contained in codebook 30 and incoming symptom vectors are provided to problem set generator 10c , which outputs a likely problem set . fig1 d shows details of one possible embodiment for codebook generator 12 . causality matrix 40 , which represents the same element as causality matrix 9 in fig1 a , contains an illustrative set of discrete probability values shown as 40m . optimized codebook 60 , which represents the same element as codebook 11 in fig1 a , contains an illustrative set of discrete probability values shown as 60m . well - formed matrix generator 12a reads values from causality matrix 40 and , through various operations described in more detail herein , removes redundant data from the matrix and generates well - formed causality matrix 50 as an intermediate product . in the illustrative example , rows 5 and 6 of causality matrix 40m have been deleted as shown in 50m . optimizer 12b reads values from well - formed causality matrix 50 and , through the use of mismatch measuring circuit 12c and a desired radius r , reduces the amount of information in well - formed causality matrix 50 to a smaller set which meets a given set of desirable criteria . optimizer 12b produces optimized codebook 60 as an output , having illustrative values shown as 60m . fig2 a to 2g show one example of how codebook 11 can be generated from causality matrix 9 . fig2 a shows a causality graph of events which may occur in the computer system being monitored by apparatus 5 . the causality graph comprises a set of numbered nodes , each representing an event in the system , and directed edges ( arrows ) connecting these nodes , each representing a causality relationship between the events at the tail and head of the edge . as can be seen in fig2 a , event 1 causes event 3 , which causes event 4 , which in turn causes event 5 , and so on . as an example , event 1 may be a disk drive failure in a peripheral attached to one of the computer nodes in fig1 a . event 3 , caused by event 1 , may be an error message generated by the computer to which the failed disk drive is attached , the error message indicating the detected disk drive failure . in this context , event 1 can be classified as a problem ( i . e ., it can be fixed ), while event 3 can be classified as a symptom caused by the problem . of course , event 3 might have other causes , such as event 5 , as indicated in fig2 a . the method and means for converting the causality graph of fig2 a into codebook 11 will now be described in detail . fig2 b shows the same information in the causality graph of fig2 a in the form of an incidence matrix comprising a plurality of rows and columns which define a plurality of cells , each cell corresponding to an intersection of one row and one column . each cell contains a value ( in this example , either 0 or 1 ) indicating whether or not a particular event is caused by another event . thus , for example , event 3 ( third column ) causes events 3 , 4 , and 7 because these rows contain a &# 34 ; 1 &# 34 ; for the third column . although zeros and ones are shown in fig2 b , the cell values can be any value which would indicate the probability that the given event causes a corresponding event . the information in the incidence matrix of fig2 b can be simplified by noting that certain events always occur in combination . for example , in fig2 a , the events { 3 , 4 , 5 } form a correlated set ( i . e ., one cannot occur without the other ), and they can therefore be combined into a single event 3 as illustrated in fig2 c whereby nodes 4 and 5 have been deleted . this first simplification of the information is thus done by replacing &# 34 ; cycles &# 34 ; in the causality graph with single aggregate nodes . the information in fig2 a to 2g may be stored in a computer memory or the like in various data structures , or it may be displayed graphically on a computer screen for manipulation by a human . one of ordinary skill in the art will recognize that this information may be represented and manipulated in various ways , and further elaboration is not required . each node in the simplified causality graph of fig2 c may be designated as either a problem or a symptom . a problem is an event that requires handling , while a symptom is an event that may be observed . an event can be designated as both a problem and a symptom , or it may be neither . for example , in fig2 d , rectangles have been used to designate nodes which are problems , and triangles have been used to designate nodes which are symptoms . thus , in keeping with the above example , event 1 is a disk drive failure ( problem ), and event 3 is an i / o error message generated by the computer connected to the failed disk drive ( symptom of the problem ). some events are of no interest and can be eliminated from the causality graph without losing any useful information . as an example , it will be noted in fig2 d that event 1 causes event 8 , which in turn causes event 9 . however , event 8 is only an &# 34 ; intermediate &# 34 ; event and contributes no new useful information . the graph of fig2 d can thus be simplified by the following steps : ( 1 ) select an undesignated event in the causality graph ( i . e ., one which has not been designated with a rectangle or triangle ). ( 2 ) for each edge leading to the event node from a first node x and for each edge exiting the node to a second node y , create a direct edge from x to y . ( 3 ) delete the undesignated event node and the lines attached to it . in accordance with this simplification , node 8 has been deleted from the causality graph of fig2 d in the simplified graph of fig2 e . all remaining nodes are now designated as either an observable symptom or a problem that requires handling . the information in the simplified graph of fig2 e can now be represented in a correlation matrix as shown in fig2 f . the matrix of fig2 f contains columns corresponding to the problems of fig2 e and rows corresponding to the observable symptoms of fig2 e . in this matrix , a symptom is correlated with a problem if there is a causal path leading from the problem to the symptom . thus , for example , problem 1 leads to ( directly or indirectly ) symptoms 3 , 7 , 9 , and 10 . accordingly , these rows of column 1 are indicated with a &# 34 ; 1 &# 34 ; while remaining row 6 is indicated with a &# 34 ; 0 &# 34 ; because there is no causal relationship between problem 1 and symptom 6 . because the correlation matrix of fig2 f may contain symptoms which do not contribute useful information for detecting problems , or it may contain problems that cannot be distinguished by the given symptoms , it is desirable to further reduce the correlation matrix to eliminate such non - informative rows and columns . the first simplification is to eliminate identical rows , because such rows indicate that the respective sets of symptoms provide identical information about the problems . for example , rows 3 , 7 , 9 , and 10 of the correlation matrix in fig2 f contain identical information , and these redundant symptoms may be eliminated as shown in fig2 g and replaced with row 3 &# 39 ; only . the second simplification is to eliminate identical columns , because such columns indicate that the respective problems cannot be distinguished by the observed symptoms . indistinguishable problems can be aggregated into a single abstract problem . this is particularly useful when a large collection of similar problems need to be handled in a similar manner . for example , various different problems with an ethernet ™ interface card ( e . g ., loose connector , defective collision - detection circuits ) all lead to similar symptoms . the problem can therefore be generally abstracted as an &# 34 ; interface problem &# 34 ; and the correlation process will only identify that such a problem exists , but will not be able to determine which specific condition ( loose connector or defective circuits ) exists . further resolution of the specific problem could then be pursued by running diagnostics . where it is not acceptable to aggregate indistinguishable problems into abstract ones , new symptoms that yield distinct columns can be added . in accordance with the above described simplification , problems 1 and 11 in fig2 f have been aggregated into a &# 34 ; problem 1 / 11 &# 34 ; in fig2 g . after the foregoing steps , the correlation matrix of fig2 g is considered to be well formed because it has distinct rows and columns . each column provides a distinct signature of the respective problem . a column vector will hereinafter be referred to as a &# 34 ; code &# 34 ; of the problem corresponding to the column representing the problem . a codebook is a set of symptoms whose respective rows in the correlation matrix provide a distinct code for every problem . the various data reductions described above can be used to convert a correlation matrix into such a codebook . however , the codebook may still contain a very large number of symptoms which contribute little to detecting or identifying problems ( although the example outlined above is , of course , small ). therefore , additional mechanisms are needed to reduce the size of codebooks while providing optimal identification of problems . one approach for further reducing the size of codebooks is to develop a measure of distance among codes and use this measure to determine the distinguishability among the codes . a process can then be used to generate codebooks that accomplish a desired level of distinguishability using a minimal set of symptoms . the hamming distance between two codes p and q is the number of coordinates where the two codes are not similar . this distance between problems p and q relative to a set of symptoms s ( rows ) will be referred to as d s ( p , q ). this distance measures the distinguishability between the codes of the respective problems for a given set of symptoms . the distance of a problem p from an entire set of problems p relative to a set of symptoms s will be designated as d s ( p , p ), which is the minimal distance between p and members of p for the given set of symptoms s . moreover , d s ( p ,{}), i . e ., the distance of a problem p from an empty set , is infinite . similarly , the radius of a set of problems p , denoted by r s ( p ), is the minimal distance between the codes of the set of problems p relative to a set of symptoms s . the radius measures the minimal ( worst case ) distinguishability between the codes of p . given a correlation matrix such as that in fig2 g , an optimal codebook can be generated by finding a minimal subset of the symptoms that provides an acceptable level of identification of the problems , where the radius provides a measure of the identification level . a codebook of a given radius is minimal if none of its symptoms can be eliminated without decreasing its radius . to summarize , given a set of problems p , a well formed correlation matrix for p , and a distance measure d such that r ( p )≧ d where s is the set of symptoms of the correlation matrix , the objective is to find a minimal set of symptoms s &# 39 ; . or right . s ( codebook ) such that r s ( p )≧ d . the creation of an optimal codebook may be performed in a &# 34 ; preprocessing &# 34 ; stage , which allows one to trade off computation time in creating the codebook for faster execution time during a decoding stage using the optimized codebook . the process for generating an optimal codebook in accordance with the aforementioned objectives will now be described with reference to fig3 a to 3b . in step 301 of fig3 a , the optimized codebook s is initialized to the null set ( s ={}), and the set of problems in p ( from the well - formed correlation matrix ) covered by the codebook is also initialized to the null set ( q ={}). in step 302 , a test is made to determine whether the problems covered by the codebook are identical to the problems covered by the well - formed correlation matrix . if all the problems are covered by the codebook s , the process continues to step 317 to generate the optimized codebook s by eliminating symptoms from s while maintaining the radius above the required one d . accordingly , step 317 is executed in which the next symptom s ( not already examined ) is retrieved from s . in step 318 , if there are no more symptoms , i . e ., all the symptoms in s have been examined , the codebook s is considered to be complete and minimal in step 303 and the process terminates and exits at step 304 , the optimized codebook being represented by s . otherwise , if there are more symptoms , the process continues to step 319 , in which the radius of the set of problems p relative to codebook s minus the symptom s is compared to the required distance d . if the radius is not smaller than d , the symptom s is removed from s in step 320 . in any case , the process iterates to step 317 . if in step 302 not all problems are covered by the codebook s , the process continues to step 305 . at step 305 , the next problem p is selected from the problem set p \ q , and the hamming distance between this problem and the problem set q covered by the optimized codebook is determined in step 306 . in step 307 , if this distance is greater than or equal to the specified distance measure d , then problem p is added to the set of problems covered by the codebook in step 308 ( i . e ., q = q ∪ { p }) and processing resumes at step 302 . executing step 308 indicates that the codebook s already distinguishes p from q by an appropriate distance . if the determined hamming distance is not greater than or equal to the distance measure d in step 307 , this indicates that the codebook s does not provide sufficient distinction for problem p and needs to be extended to meet the desired quality measure d . accordingly , step 309 is executed , in which the next symptom s ( not already covered in s ) is retrieved from the well - formed correlation matrix . in step 310 ( fig3 b ), if there are no more symptoms , this indicates that all the symptoms not included in optimized codebook s have been examined , and step 311 is executed . in step 311 , one symptom is selected from all the candidates previously generated in step 316 ( discussed below ), the one selected being the one which maximizes the distance d s ∪{ s } ( p , q ). this selected symptom is added to s ( i . e ., s = s ∪ { s }) and processing resumes at step 307 . if , on the other hand , there are more symptoms to consider in step 310 , the subset of problems q &# 39 ; of q is determined in step 313 . q &# 39 ; is the subset of problems of q such that the hamming distance of every problem q . di - elect cons . q &# 39 ; from p relative to the codebook s , d s ( p , q ), is equal to the hamming distance of p from the entire set of problems q , d s ( p , q ). then , s can be a candidate only if by adding it to the codebook s the distance of p from a member of q &# 39 ; increases . hence , in step 314 , a search for a problem q . di - elect cons . q &# 39 ; such that d s ∪{ s } ( p , q )& gt ; d s ( p , q ) is performed . if such q does not exist , the symptom s is ignored ( step 315 ). otherwise , s is considered to be a candidate for s in step 316 , and processing resumes at step 309 . the above process can be used to generate an optimal codebook from a well - formed correlation matrix . the process is finite due to the specified restriction r ( p )≧ d . when the process terminates at step 304 , the set q equals the set p and all problems are covered by the optimal codebook s . moreover , the optimal codebook s satisfies the distinguishing criterion d ≦ r s ( p ) and is minimal . the complexity of the process is polynomial in the number of problems and symptoms . the process can be incrementally applied with minor variations to handle additional new problems by simply extending the codebook to cover the new problems . there is no need to regenerate the entire codebook . similarly , if certain symptoms become unavailable , they may be replaced with new symptoms by extending the codebook rather than regenerating it . this flexibility to handle changes in the codebook may be important in an environment where the problems of interest and the observable symptoms can vary . distance measures other than hamming distances can , of course , be used , and the invention is not limited in this regard . the above discussion explains how to generate a codebook from a causality graph by first generating a causality matrix and then selecting a codebook . it will be recognized , however , that a codebook can be generated directly from a causality graph without first generating a causality matrix . as outlined above , the following mappings can be made between a causality graph and a causality matrix : ______________________________________graph causality matrix______________________________________symptom node rowproblem node columndirected path from event to a matrix cellproblem nodeweight on path probability ( correlation symbol ) set of symptom nodes code of a problemreachable from a problemnode via directed paths . s ( p ) = symptoms of p . size of difference among two hamming distancesets of nodes . linevert split . s ( pl ) δs ( p2 ). linevert split . among codesa minimal difference set radiusamong symptoms set of twoproblems . r = min {. linevert split . s ( pl ). increment . s ( p2 ). linevert split . ; p1 , p2 } ______________________________________ the mappings above can also be used to generate a codebook directly from a graph by mimicking the process for the causality matrix . thus , direct generation of the codebook can be performed by the following steps : ( 1 ) simplify the causality graph as explained with reference to fig2 a to 2e . ( 2 ) eliminate redundant nodes ( problems and symptoms ) from the causality graph . two symptom nodes are distinguishable if they share the same set of problems that lead to them via directed paths . two problem nodes are distinguishable if they lead via directed paths to the same set of symptoms . thus , problem and symptom nodes that are redundant because of indistinguishability are eliminated . ( 3 ) select symptoms that distinguish problems to within a given desired distance . in many cases , symptoms may be randomly caused by problem events . a probabilistic correlation model is a matrix which contains for each problem p ( column ) and each symptom s ( row ) the conditional probability that s will be caused by p . this is really just a special case of the general model outlined previously where the probabilities were 0 or 1 . where it is difficult to obtain accurate estimates of the probabilities , discrete probability values such as high ( h ), medium ( m ), or low ( l ) may be used to indicate relative probability levels . that is , the elements of the correlation matrix may take on values from the set { h , m , l }. temporal correlations among events may also be indicated by values which represent a time period from the occurrence of the problem until generation of the symptom . additionally , temporal correlations among symptoms may also be specified . in either case , a discrete measure from the set comprising { l ( long ), m ( medium ), s ( short ), 0 ( never )} may be used . the above correlation measures may be combined to refine the correlation model . for example , the correlation matrix may include pairs of the form { pr , t ) where pr is a probability indication from { h , m , l } and t is a time indication from { l , m , s , 0 }. the pair ( h , s ) in the correlation matrix would indicate that the respective problem may cause the symptom with high probability over a short time window . a correlation matrix whose columns correspond to members of p , whose rows correspond to members of s , and whose elements are indicators from i . a distance measure δ : i × i →, where is the set of non - negative real numbers . this measure δ provides the distance ( asimilarity measure ) between two correlation indicators . for example , the deterministic correlation model described above is obtained when the set of indicators is i ={ 0 , 1 } and the hamming distance ( a similarity measure ) function is given by the relation : where the columns and rows represent the indicator symbol and the numbers in the matrix represent the respective hamming distance measure . note that absence of a symptom ( 0 ) perfectly matches absence of a symptom ( 0 ) and therefore has no mismatch ( 0 ). given a generalized correlation model , the code of a problem p is the vector of indicator values of the respective correlation matrix column . the distance between two such codes p and q is given by the following function : d s (, p , q )= σ s . di - elect cons . s δ ( p s , q s ) where p s is the coordinate of p corresponding to the symptom s , that is , the component of the correlation matrix in column p and row s . in the case of the deterministic correlation model , the distance between two codes , determined using δ h in the table above , is the number of coordinates where the vectors have different components . once a distance function between codes is defined , the definition of radius described previously can be applied . therefore , the codebook generation problem and process described above can be generalized , and the process of fig3 can be used for a generalized correlation model when the appropriate distance function is used . an example will now be provided to illustrate how this generalization can be applied to solve the problem of generating a codebook for a probabilistic correlation model . assuming a correlation matrix which uses indicators from the set i ={ h , m , l } for high , medium or low probability , the following is an example of a distance measure ( measure of mismatch ) which can be used : ______________________________________δ 1 m h1 0 α 1m α 0 βh 1 β 0______________________________________ in the above example , the factors 0 ≦ α , ( β )≦ 1 measure the similarity between medium and low probability ( respectively , high and medium probability ). a possible choice , for example , is α = β = 0 . 5 . the above defines a distance measure among probabilistic codes . for example , consider the following two codes for problems using a codebook of 6 observed symptoms : ## equ1 ## by selecting various measures of similarity , different strategies can be reflected to measure distinction between codes . for example , in distinguishing among codes , all symptoms having a medium probability of occurring can be ignored . this would be reflected by setting α = β = 0 . the distance between p and q in the above example would thus become : this distance reflects coordinates where one problem is very likely to show a symptom while the other problem is unlikely to show the symptom . coordinates where symptoms provide uncertain signals are ignored . the codebook generation process as described above will yield a minimal one whose codes are sufficiently distinct in the sense of distance between probabilistic codes defined above . of course , in the real world , many probabilistic correlations may be unknown , and the model cannot be tailored to take advantage of these relationships as described above . however , one of ordinary skill in the art will recognize that the correlation model can be easily tailored to accommodate different systems and make use of all available information as needed to practice this aspect of the invention . once an optimal codebook for a given set of problems and symptoms has been generated as outlined above , the optimal codebook can be used to decode symptoms which occur during system operation and to generate reports indicating detected and / or identified problems ( see fig1 a ). the event decoder 10 of fig1 a classifies a vector of observed symptoms into the most appropriate code . generally , symptoms are either observed or not observed , but the principles of the invention are easily applied to probabilistic determinations where observations are uncertain . for example , suppose that a codebook contains 6 symptoms . an observation described by a =( 0 , 0 , 1 , 0 , 1 , 1 ) indicates that symptoms 3 , 5 , and 6 were detected while the other symptoms did not occur . assuming there is no problem whose code is an exact match for a , the codes of problems p and q , given by p =( 0 , 0 , 1 , 0 , 0 , 1 ) and q =( 1 , 0 , 1 , 0 , 1 , 1 ) are very similar to a . in a real system , symptoms may be lost or generated spuriously , so it is necessary for the decoding process to find the &# 34 ; best fit &# 34 ; problem even though none matches exactly the set of symptoms . one method of finding the &# 34 ; best fit &# 34 ; problem is to use a mismatch measure . the hamming distances between the two observed symptom vectors d ( p , a )= d ( q , a )= 1 are identical since both codes differ from the observation vector in one symptom only ( 5 for p and 1 for q ), however , there is an important difference between p and q with respect to their similarity to a . the observation a could be caused by p if symptom 5 were lost , but for q to be the cause of the observation a , symptom 1 would have to be spuriously generated , which in most systems is less likely than losing messages . the concept of a mismatch measure can help capture this likelihood to determine which problem is a better match for a given set of symptoms . event decoder 10 of fig1 a would thus be able to select p as the more likely explanation of the observation a . a mismatch measure can be defined as a function ∂: { 0 , 1 }× i →, which assigns to a symptom ( 1 if the symptom is observed , 0 if it is not observed ) and a corresponding correlation indicator i , a measure of mismatch between the observation and a code . the value of ∂( 1 , i ) measures the mismatch between an observation of a symptom and a code where it occurs with correlation i . similarly , ∂( 0 , i ) measures the mismatch between the lack of observation of a symptom and a code where it occurs with correlation i . for example , in the deterministic correlation model i ={ 0 , 1 }, if an observed symptom matches the expectation of a code ( i . e ., it matches that symptom &# 39 ; s entry in the codebook ), then the degree of mismatch is given by ∂( 1 , 1 )=∂( 0 , 0 )= 0 . this means that if the code expects the symptom to occur ( or not to occur ) and it is observed ( or is not observed ), there is a perfect match between the observation and the code . if the code expects a symptom to occur but the symptom is not observed ( e . g ., due to loss ), the measure of mismatch ∂( 0 , 1 )= α assigns a weight to loss of the symptom . similarly , a spurious generation of a symptom not anticipated by a code will carry a mismatch measure of ∂( 1 , 0 )= β . if α is chosen to be smaller than β , this would indicate a greater mismatch for a spurious event . mismatch measures may be described using tables in a manner similar to distance measures . columns represent correlation symbols , while rows represent observations { 0 , 1 }. for example , the mismatch measure for the deterministic model is given below : for a probabilistic correlation model , a possible mismatch measure is given by : the above mismatch measure can be interpreted as follows . when a code expects a symptom with low or medium probability , absence of the symptom has no mismatch with predictions ∂( 0 , 1 )=∂( 0 , m )= 0 . when the code expects a symptom with high probability , absence of a symptom has a mismatch of level α . similarly , occurrence of a symptom expected with high or medium probability matches the expectation , while occurrence of a symptom expected with low probability represents a mismatch of level β . a mismatch measure m can be defined between an observation vector a and code p as the sum of the mismatch measures between respective coordinates : this mismatch measure represents the degree to which the observed and absent symptoms of a match the code of p . it is expressly understood that the term &# 34 ; mismatch measure &# 34 ; can be more generally referred to as a correlation measure or correlation distance without limiting its application in the present invention . the above described tables can thus be replaced by measures of correlation ( similarity ) to produce the same results . a decoder for a correlation model over a codebook s can be defined as a process that maps an observation a to the set of problems whose codes have minimal mismatch with a . thus , given a codebook s , a set of problems p with codes over s , and a mismatch measure m s , an input observation a over s will be decoded , and an output will be generated corresponding to all problems p that minimize m s over p . with reference to fig4 a and 4b , the decoding process will now be described in detail in accordance with the above objectives . in step 401 , q ( the set of problems to be considered ) is initialized to p , p * ( the set of decoded problems ) is initialized to the null set , and m * ( the minimal mismatch ) is initialized to infinity . in step 402 , a test is made to see if the set of problems to be considered has been exhausted . if so , step 403 is executed , in which all decoded problems are returned and the process exits in step 404 . assuming there are still problems to be considered , in step 405 a problem is selected from q and the problem is removed from q . in step 406 , the mismatch m s ( a , p ) is determined between the observed vector a and the problem p as described previously . in step 407 , the determined mismatch is compared with the current minimal mismatch m *. if the newly determined mismatch is less than the current minimal mismatch , then step 408 is executed . in step 408 , a new value for m * is assigned corresponding to the newly determined mismatch , and the problem p corresponding thereto is inserted into p * ( i . e ., the decoded problem set ). processing then resumes at step 402 . if , in step 407 , the determined mismatch is not less than the current minimum mismatch value , a test is performed in step 409 ( fig4 b ) to determine whether the determined mismatch is equal to the current minimum mismatch value . if they are equal , step 410 is executed , in which the problem p is added to the decoded problem set p *. it will be noted that multiple problems could have the same degree of mismatch and thus more than one problem could be inserted into p * in this instance . finally , if the newly determined mismatch is not equal to the current minimal mismatch m * in step 409 , the only remaining possibility is that it is greater than m * ( step 411 ). in this case , processing resumes at step 402 . when all problems have been considered , the decoded problem set p * is generated as an output in step 403 . the complexity of the above process is determined by step 406 . the mismatch measure requires additions of | s | terms and then this is repeated | p | times , so the overall complexity is of the order | p | | s | additions and | p | comparisons . the process is suitable for executing in real - time and , due to the reduced complexity and amount of data in the optimized codebook , the amount of computation over other approaches is greatly reduced . particularly in very large and complex systems , the increase in performance can be substantial . the decoding process can be modified slightly to identify , instead of &# 34 ; best fit &# 34 ; matches for a given observation , codes which match the observation up to a particular level of tolerance from the &# 34 ; best &# 34 ; mismatch . that is , a level of tolerance t can be set and all codes that are within a mismatch of t above the minimum mismatch will result in the corresponding problem being output as part of the decoded problem set p *. to accomplish this , steps 407 and 409 of fig4 would be modified slightly to compare m s ( a , p ) with m *+ t rather than m *. to summarize the above description of the decoding process , the steps in fig4 determine the minimally mismatched codes that would explain a given observation vector . the measure of mismatch used can be selected to reflect a variety of considerations and sensitivities specific to a given system . due to the simplicity of the decoding process ( i . e ., involving simple operations such as additions and comparisons ), the process can be executed very fast and in real time . in order to more clearly illustrate the principles of the present invention , a specific example will now be described in detail with reference to fig5 a to 5e . fig5 a shows a well - formed deterministic correlation matrix ( i . e ., all problems cause certain symptoms with certainty ) for 6 problems p producing 20 symptoms s . the hamming radius for these problems is r ( p )= 7 ( i . e ., the minimal distance of 7 is obtained between problems 1 and 3 and between problems 2 and 3 ). one can thus generate optimal codebooks for p that accomplish a hamming distance of up to 7 . fig5 b shows the generation of an optimal codebook with a target distance measure of d = 1 . assuming that the problems are considered in order of 1 to 6 and symptoms are considered in order from 1 to 20 , fig5 b shows seven &# 34 ; snapshots &# 34 ; of codebook s and problem set q as the process illustrated in fig3 is performed . at the seventh snapshot in fig5 b , the optimal codebook is complete with s 1 ={ 1 , 3 , 4 } and a corresponding matrix as shown in fig5 c . thus , the correlation matrix of fig5 a has been simplified to that of fig5 c for a distance measure of 1 . as another example , fig5 d shows an optimal matrix for the same correlation matrix of fig5 a ( codebook s 2 ={ 1 , 2 , 3 , 10 , 15 }) generated with a radius of 2 instead of 1 . this illustrates how even small codebooks can be optimized to accomplish a significant level of distinction . in order to perform decoding using either codebook s 1 or s 2 , a sample mismatch measure shown in fig5 e will be used starting with α = 1 and β = 10 ( this is sufficiently large to prefer lost symptoms to spurious ones in selecting codes ). assuming that codebook s 1 is used , note that there is only one combination of symptoms which does not directly match one of the problems ( i . e ., there will be only one mismatch ), which is a =( 0 , 0 , 1 ). the trivial observation vector a =( 0 , 0 , 0 ) is always excluded . using the values of α = 1 and β = 10 , the mismatch measures of a with the codes of the 6 problems are given by 2 , 11 , 12 , 11 , 1 , 1 . in this case , problems 2 , 3 , and 4 would require a spurious generation of symptom 4 to generate a . since spurious events are penalized with a high mismatch level ( β = 10 ), these codes are greatly mismatched with a . the decoding process will thus result in { p 5 , p 6 } returned as the &# 34 ; best &# 34 ; decoding of symptom vector a . thus , either problem 5 or problem 6 could have generated the observation through the loss of a single symptom . the above example will now be repeated for codebook s 2 . with the 5 symptoms shown in fig5 d , the number of possible non - trivial observations is 31 , of which only 6 are exact codes . considering first observations resulting from the loss of 1 symptom in the codes , since the distance among the codes in fig5 d is at least 2 , none of these observations can be a code . this set includes the following 15 observations : { 11000 , 10100 , 01100 , 00110 , 01010 , 01111 , 10111 , 11011 , 11101 , 11110 , 10010 , 00011 , 00101 , 00001 , 10000 }. these observations will be decoded into the codes at distance 1 from which a symptom is lost . this means that at most two codes will be decoded from these observations . considering observations generated when two symptoms are lost , this set includes the 10 observations { 00100 , 00010 , 01000 , 10101 , 10011 , 11001 , 10110 , 01110 , 01101 , 01011 }. the first 3 may be generated by multiple codes , while the remaining 7 may only be generated from the code for problem 3 by deleting two symptoms . that is , each of these 7 observations will be decoded as problem 3 . fig6 shows how the principles of the present invention can be applied in a system which includes satellites communicating with a ground station . in fig6 elements 606 to 613 perform functions identically or similar to those of elements 6 to 13 in fig1 a . a ground station 620 communicates with a plurality of satellites 621 , 622 and 623 by way of radio wave propagation . each satellite may typically comprise numerous processing components including sensors and devices which may generate symptoms such as low power , device failures , and the like . these symptoms can be transmitted to ground station 620 , which is connected to event detector 606 . in accordance with the detailed explanation previously provided , the invention decodes events which occur during system operation and generates a report 614 corresponding to the one or more likely problems in the system . because the number of events in the system of satellites can be quite large and the relationships among events complex , the data reduction principles of the present invention can result in significant performance advantages over conventional approaches . the satellites shown in fig6 may comprise a telecommunication system , for example . instead of satellites , elements 621 - 623 may instead comprise ground - based telecommunication nodes having switches and multiplexors which may generate symptoms . fig7 shows how the principles of the present invention can be applied in medical diagnosis applications . elements 706 to 713 perform the same or similar functions as elements 6 to 13 of fig1 . one or more sensors 720 may receive symptoms from a patient such as temperature , blood pressure , chemical levels , breathing rate , and the like . moreover , a doctor may manually enter other symptoms through input means 721 , such as through a menu . these symptoms could include not only those directly observable such as skin color , pain locations and the like , but could also include derived symptoms such as partial diagnoses based on the doctor &# 39 ; s own knowledge or suspicions . symptoms from sensors 720 and input means 721 are fed to event detector 706 in a manner similar to that for other embodiments of the invention . based on the observed symptoms , the invention produces a report 714 or other indication of the likely diagnosis , such as on a graphics display or the like . the apparatus of fig7 may also be used to analyze financial market events by replacing sensors 720 with an appropriate data collection device ( such as a computer program or other statistical filtering device ) to compile prices , ratios , trends , etc . into events for event detector 706 . in place of doctor input 721 , an input device suitable for receiving human - observable events may be provided so that a market analyst may input such events . it is possible to use an alternative decoding process that is entirely built upon table lookup . a perturbation analysis can be undertaken to divide all possible observations into appropriate classes . for each such perturbation , one can determine all codes from which it obtains . the decoding table may be generated in advance , and decoding becomes a simple and fast table lookup process . this is particularly useful when the code is efficient . the size of the lookup table could be 2 . sup .| s |. in general , this may be very large . however , for efficient codes , | s |˜ log | p | and , therefore , the size of the lookup table is of a similar order as | p |. the codebook has a large radius , the codes could admit significant perturbations while accomplishing unique decoding . this is entirely analogous to the design of error - correcting codes . with sufficient redundancy in the codebook , decoding can be very robust to lost or spuriously generated symptoms . the larger the radius of the codebook , the smaller the number of ambiguous observations that will exist . when the radius is r , the number of observations that decode into a given code is approximately 2 r / 2 , leading to a total of some | p | 2 r / 2 points that decode unambiguously . this represents a fraction of the observations space of approximately | p | 2 r / 2 - | s |. when | p |˜ log (| s |- r / 2 ), then most problems will be decoded unambiguously . in summary , the principles of the invention outlined herein offer significant advantages over other approaches to event correlation and management , including the following : ( 1 ) real - time correlation computations are reduced significantly by preprocessing event knowledge to generate codebooks prior to real - time event detection and correlation . this is in contrast to typical event correlation systems based on artificial intelligence techniques which conduct indefinite searches during real time to correlate events . in extremely large and complex systems , the reduction in real - time processing requirements can significantly reduce the amount of hardware required and can result in faster problem diagnosis . ( 2 ) a wide range of correlation models can be used and tuned ( through a choice of correlation indicators , distance and mismatch measures ) to achieve different strategies for correlation while using the same generalized process . ( 3 ) the set of events to be monitored can be narrowed to only those that provide the highest information benefit , rather than arbitrarily monitoring all possible events , or an ad hoc set of events . this reduces the complexity of the correlation process and minimizes the waste of computer processing resources . ( 4 ) the instrumentalities of the invention can be implemented with a relatively small set of code that can be operated on a single computer . in addition to creating causality matrices manually , they may be generated through the use of a formalized language which verifies various data relationships and creates a matrix , or they may be created semi - automatically using statistical analysis and filtering using well - known techniques . thus , event capture 7 and event validation 8 shown in fig1 a may be used to generate causality matrix 9 using either approach shown in fig8 as described in more detail below . the left side of fig8 shows how events which result from event detector 6 ( see fig1 a ) may be processed using elements 801 through 806 to generate causality matrix 807 ( these elements also illustrate the process which may be used ). alternatively , the right side of fig8 shows how causality matrix 807 may be generated from an event model 809 , an event propagation model 810 , and a configuration specification 812 . the latter approach provides significant benefits in that a formal , automatable process is provided for generating causality matrix 807 for a dynamically changing system from static event knowledge associated with the types of components in the system and the dynamic specification of a particular configuration . either approach may be implemented using computer software and corresponding data files , and the resulting causality matrix 807 may be stored in a storage device such as a computer disk for later access . of course , variations on the approach shown in fig8 are possible , and the two illustrated are not intended to limit the scope of the invention . beginning with the left side of fig8 events received from event detector 6 ( see fig1 a ) are logged in event logger 801 . this element may time - stamp the event and record &# 34 ; what happened &# 34 ;; for example , a disk drive error in one of the networked computer nodes illustrated in fig1 a . these events may be stored in an intermediate data file ( not shown ) for statistical analysis by element 802 . statistical analysis 802 analyzes the data produced by element 801 to identify correlations among events , and may be performed either in quasi - real time or in an off - line mode using historical data collected over a long period of time . statistical analysis 802 may be performed using any well - known method , such as multiple linear regression analysis , and a detailed explanation of these well - known methods is not provided here . the purpose of element 802 is to identify correlations among events which are detected in the system ( i . e ., identify events that occur in pairs , where one event probably causes another event ), and to store the correlation information into a data file 803 . after correlations among events are stored in data file 803 , a filter 804 is applied to this data to remove weakly correlated data . this may be done by allowing a user to specify a particular correlation threshold or any other means to weed out weakly correlated events . the filtered data is then formatted into causality matrix 807 through the use of matrix generator 806 in accordance with the description of this matrix as previously described . each of these operations can be programmed easily using a digital computer and any suitable computer language , such as c , fortran , or lisp . referring now to the right hand side of fig8 a process and means for creating causality matrix 807 by applying an event model 809 , an event propagation model 810 , and a particular system configuration 812 will be described . the gdme specifications shown in fig8 represent one possible embodiment of a formal language for specifying the event and propagation models . such a language may be processed by a compiler 808 , such as a gdme compiler which reads &# 34 ; statements &# 34 ; read from a file or entered by a user . other possible embodiments include languages with a different syntax from that described herein , different data structures , graphical representations , or any other means of specifying the static information in event model 809 and propagation model 810 . any particular system monitored using the principles of the present invention can be characterized by a domain consisting of a set of objects ( hardware , software , communications or others ) which can generate events . these objects within the domain will be called event source objects ( esos ), indicating that each such object can be the source of one or more events . each eso can be characterized as belonging to a particular class , and each can be related to other esos via certain relationships . for example , a power supply object may be related to a cpu board object via the relationship &# 34 ; provides - power - to &# 34 ;. events may propagate among such relationships . for example , a problem event in the power supply may cause symptom events ( as well as problem events ) at the cpu board and other objects to which it &# 34 ; provides - power - to &# 34 ;. the information required to analyze events can be divided into two kinds : ( 1 ) generic knowledge about events associated with eso classes . this knowledge may comprise an event model and an event propagation model which can be provided by the designer of each component at design time . the class to which an eso belongs determines the set of exceptional events ( problems ) that may occur in the component , the local symptoms they cause , and the probability that they may cause these local symptoms . this information constitutes the event model for the class . the class to which an eso belongs also may determine the set of relationships that esos of the class may participate in . events may propagate along relationships to and from related esos . for example , the knowledge of various events of a power supply component and the manner in which these events may cause events occurring at esos to which the component &# 34 ; provides - power - to &# 34 ;. this knowledge is typically generic to various types ( classes ) of esos . the specification of which class events may propagate along which relationships constitutes the event propagation model for the class . ( 2 ) specific knowledge about the set of specific instances of esos in a domain , and their specific relationships . for example , a given domain may include 14 workstations , each of which contains an instance of a power supply object and of various boards which this specific power supply object &# 34 ; provides - power - to &# 34 ;. this data is assumed to be organized into a configuration specification for the particular domain , illustrated by element 812 in fig8 . any data representation may be used to store this data , such as a memory data structure , a file , an object - oriented database , or others . matrix generator 811 generates causality matrix 807 by interpreting event and propagation models 809 and 810 , respectively , in a domain specified by configuration specification 812 . this process may be performed either with compiler 808 using compilable statements or specifications ( as described in more detail herein ), or directly from event model 809 and propagation model 810 . the interpretation may be performed as follows : ( a ) determine the set of all events ( exceptional and observable ) that can occur in the specific configuration . each object in the configuration may generate any of the events specified for its class in the event model . the set of events in a given configuration is thus the union of all events that can be generated by all the objects in that configuration . ( b ) determine the causality closure . for every event in the set determined in step ( a ) above , the causality closure is the union of all observable events the event may cause and the probability it may cause each of them . this causality closure may be determined through the following recursive steps : ( 1 ) if the event is an observable event then its causality closure is the single element set consisting of the event itself . ( 2 ) if the event is specified as an event that may cause a set of symptoms s 1 , . . . s m , then the causality closure of that event is the union of the causality closures of s i , where i = 1 . . . m . ( 3 ) if the event is specified in the propagation model as an event that can propagate via certain relationships , and the configuration specifies that the object generating this event is related to objects o 1 , . . . o n via those relationships , then the causality closure of that event is the union of the causality closures of the corresponding imported events in o i , where i = 1 . . . n . as illustrated in fig8 gdme specifications may be input to compiler 808 in fig8 in various embodiments of the invention as described in more detail below . however , alternative forms of specifications may be used , such as graphical representations , and the invention is not intended to be limited in this regard . in various preferred embodiments , the gdme specifications may comprise the following compilable statements input to compiler 808 : interface statement : defines a class of event source objects and provides the start of a definition block . all statements between an interface statement and an end statement are associated with a definition block . a preferred statement syntax is : where class - name is an alphanumeric name of the new type of objects being defined , and parent - class - name is an alphanumeric name of the generic type of objects the new class inherits from . the parent class must be either a &# 34 ; basic &# 34 ; class of the data model or a previously defined class . attribute statement : specifies an attribute , property and / or real - time measurement of an object . a preferred syntax for this statement is : where attribute - name is an alphanumeric name of an attribute which is unique within the scope of the definition block , and attribute - type is the one of the pre - defined set of basic types . event statement : specifies an event that might be generated by objects in the class . each event is specified by an event statement as a boolean expression on properties of the class or as a user function . a preferred statement syntax is : where event - name is an alphanumeric name of an event unique within the scope of the definition block , description is quoted free text that describes the event and / or associates an action with it ( intended for presentation to human operators ), and expression is either a boolean expression in terms of the object &# 39 ; s attributes and events or a function name to be used to detect the event . import statement : specifies an event that an object in the class may import from another object . the event may propagate from an object of this class to other objects via one of the relationships that exists between the respective objects . a preferred statement syntax for this statement is : where event - name is an alphanumeric name associated with the imported event used to uniquely identify the event within the scope of the definition block ; description is a quoted free text string that describes the event and / or associates an action with it ( a programmed action or one intended to be presented to human operators ); class - name is an alphanumeric name of the class from which the following events are imported ; relationship - name is an alphanumeric name of one of the relationship attributes of this class ; and imported - event - name is an alphanumeric name of an event being imported from the specified class . causality statement : specifies a problem which may cause a set of observable events in the instances of the class . observable events are those specified by an event or import statement . a preferred syntax is : where problem - name is an alphanumeric mane of a possible problem with an object of the class ; description is a quoted free text string that describes the problem and / or associates an action with it ( a programmed action or one intended to be presented to human operators ); symptom is an alphanumeric name of an observable event specified by either an event or import statement ; and probability may be l ( low ), m ( medium ), or h ( high ). export statement : groups set of events into a single abstract event . only events specified by an export statement are exported to the external world outside the class instance . a preferred syntax for this statement is : where aggregate - name is an alphanumeric name of an abstract problem exported by the object , description is a quoted free text string that describes the problem and / or associates an action with it ( a programmed action or one intended to be presented to human operators ); and event - name is an alphanumeric name of an event that is specified by an event , import or problem statement . end statement : terminates each definition block ; each end statement should have a corresponding interface statement . a preferred syntax is : where class - name is an alphanumeric name of the class being defined in the interface statement . to summarize the foregoing syntax , gdme specification statements specify event knowledge associated with each object class ( event statements ); the events that may occur in objects of the class and the symptoms that each such problem may cause ( causality statements ); the events that may propagate to objects of the class from other related objects ( import statements ), and the events that can be externally observed in objects of the class ( export statements ). other choices of syntax for specifying event and event propagation information may be equally suitable for this purpose . having described in detail syntax for various preferred gdme specifications , the operation and construction shown in the right half of fig8 will now be described for an embodiment which uses a gdme formal event model . gdme statements comprising a plurality of the above statements are entered by a user into gdme compiler 808 . the statements may be tailored for the particular system being monitored and the specific classes , attributes , probabilities and other parameters will be selected according to the particular type of system . gdme compiler 808 , which may be constructed using the normal parsers and other well - known components in the software engineering field details of which are not provided here , generates event model 809 and propagation model 810 for each eso class . these models are used by matrix generator 811 to analyze the events and causality associated with a specific domain described by the collection of entities and relationships stored in configuration specification 812 . event model 809 , for an embodiment using a formal gdme event model , is a data structure comprising , in various preferred embodiments , three things : ( 1 ) a list of all events associated with a class . each event has a name and a method ( or procedure ) to evaluate the expression specified by the event statement to determine whether the event condition holds . this list and the required methods are generated by compiler 808 from the event statements . ( 2 ) a list of problems associated with a class . for each problem , a list of events it may cause is included , each specifying the probability of this causality . this list is generated by compiler 808 from the causality statements . ( 3 ) a list of aggregated events associated with a class . each aggregate event has a name and a method to evaluate it . an aggregate event holds if any of the events it aggregates holds . this list is generated by compiler 808 from the export statements . propagation model 810 is a data structure comprising a list of all relationships associated with a class . it may additionally contain methods that are generated for determining the closure of the events that may propagate to other objects . this information may be generated by compiler 808 from the import statements . matrix generator 811 , which differs from matrix generator 806 , generates causality matrix 807 from event model 809 , propagation model 810 , and configuration specification 812 using steps illustrated in fig9 . with reference to step 901 in fig9 matrix generator 811 first determines the set of problems as the union of all the problems of all the esos in the domain . these are determined by the class of each eso recorded in event model 809 and appearing in configuration specification 812 ( fig8 ). next , at step 902 , matrix generator 811 determines the set of symptoms in the domain as the union of all the symptoms of all the entities in the domain . finally , at step 903 , each element of the causality matrix is generated using the direct causality stored in event model 809 , and using the indirect causality ( events imported from other objects via relationships ) by using the transitive closure of causality propagation using propagation model 810 . the transitive closure may be determined via methods generated by compiler 808 , or by other means . these methods encapsulate the event propagation model and use the configuration specification to infer the possible paths for propagation of events required in computing the closure . the resulting causality matrix 904 is used to generate an efficient codebook as described previously with relation to fig1 a . according to the above description , there is provided a method and apparatus for specifying , detecting and identifying exceptional events ( such as problems ) in a system having observable events . although many of the examples contained herein relate to computer networks , it is expressly understood that such examples do not in any way limit the scope of the invention . using the teachings contained herein , one of ordinary skill in the art will be able to practice the invention in any system which produces observable events . it is apparent that many modifications and variations of the present invention are possible in light of the above teachings , and references to specific values or paradigms are by way of example only . it is , therefore , to be understood that within the scope of the appended claims the invention may be practiced otherwise than as specifically described . as one example , the invention may be practiced by distributing the decoding process across a number of computers , such that a complex system domain is partitioned into smaller domains , each domain having a local event correlator . event correlators for the different domains may operate concurrently and interact with one another to selectively import / export events from one another . numbered steps in the appended method claims should not be considered as limiting the particular order in which the claimed steps are practiced .