Sunday, April 29, 2012

Metin Atmaca 030080007 10th week definitions part 3


3. CUSUM ( cumulative sum control chart) (Quality Control):

There is no previous definition.

Definition:

Objective monitoring or quality control has been used for surveillance: methods have been developed to detect increases in rare events, such as birth malformations and to detect minimal epidemics. A review of the concepts and definitions of quality control procedures that are commonly used in clinical chemistry have also been presented.The use of the cumulative sum (cusum) has been suggested for both surveillance and quality control. Its use for examining sequential measures or for looking for changes over time has recently been described. It has also been used for plotting temperature charts for assessing antimicrobial treatment in neutropenic patients.

Because the cusum shows changes over time it can be used by individual practitioners to monitor their own performance as a form of quality control to give proof of ongoing competence in a particular skill. It can also be used to show progress in mastering a new technique. One advantage of this sort of self assessment is that an acceptable level of attainment must be defined so that how well it is met can be quantified. It has been suggested, for instance, that the completion rate for colonoscopic examination should be above 90%.

The cusum has been described as a useful graphical tool for discerning trends. For a series of observations XI, X2, . . . Xn the cusum can be defined as

Sn = Σ(Xi-X0)

where Xi= 0 for a success and Xi= 1 for a failure. Xo is a reference or target value. The cusum is interpreted by looking at its gradient or slope. For a series of observations which meet the specified criterion the cusum should be relatively level. If the reference value is specified in terms of an acceptable failure rate, for instance, the cusum will increase and consequently will have a positive slope when the failure rate is higher than the target value, and it will decrease when the failure rate is lower than that specified. This means that if the failure rate were specified as 10%, for instance, 0 9 would be added to the cusum for a failure and -0.1 for a success. In a series of examinations consisting of a success followed by a failure and four successes the cusum would take the values -0.1, 0.8, 0.7, 0.6, and 0.5.

EXAMPLE

The first example concerns the outcome of the 361 examinations done by the experienced colonoscopist; the cusum is shown in figure 1. As it had been suggested that an acceptable failure rate for colonoscopies should be less than 10% this value was used as the reference or target value for the cusum. As a failure rate of 20% was considered unacceptable boundary lines were constructed to identify series of observations in which the failure rate increased to 20% or more. It was found that, with a small amount of rounding, a boundary line 2.5 units above the horizontal axis provided a small risk of accepting an unsatisfactory series of observations and of rejecting a series of observations that were satisfactory. By drawing a series of lines 2.5 units apart it was possible to monitor the overall performance of the colonoscopist; the inter-section of any of these lines from below marked a period that included more failures than expected. Where this happened the boundary line became the new target line.

The cusum cut the boundary line for the first time after 27 colonoscopies, which included six failures. The overall failure rate for these was 22%. The cusum intersected with the second boundary line after a further 38 examinations, which included six failures (failure rate 16%). It cut the same boundary line again at the 164th observation, the preceding four observations having included three failures. Some sections of the graph represent long runs of successes, the longest of which was 43. After such a long run the target line should be recentered by moving it to the one below.

It is impossible to tell from a retrospective analysis whether the alarms were the consequence of poor operator performance, an unusual run of technically difficult colonoscopies, or instrument malfunction. The control chart is especially sensitive to short runs of failures, and identified them quickly. It could be argued that this was a shortcoming as in a retrospective analysis it can be seen these short runs were of little consequence. Had the failures persisted, however, it would be an advantage to identify such periods as soon as possible.

(Williams, S. M., et al, Quality Control: an application of cusum, p. 1359)





4. CIMOSA (Computer Integrated Manufacturing Open System Architecture) (Modelling)



There is no previous definition.


Definition:
CIMOSA (CIM Open System Architecture) provides a process oriented modelling concept that captures both the process functionality and the process behaviour (Fig. 3). It supports evolutionary enterprise modelling, e.g., the modelling of individual enterprise domains (DM) which may contain one or several individual processes (P-1, P-2, …). Domains and processes are defined by the user according to his/her needs for controlling the business operations. Processes themselves should be defined as significantly large pieces of functionality which produce a certain end-result for a defined customer. Customers may be internal or external to the enterprise.

Fig. 3

CIMOSA always models the relations to the internal and external environment (in terms of events and results). This allows models to be integrated with other process models at a later point in time. The relations will become the links to the added models.
To handle complexity, CIMOSA follows an enterprise engineering concept which separates functionality (EA=Enterprise Activity) and behaviour (BRS=Behavioural Rule Set) allowing to change one without having to change the other.

Large processes are broken down into smaller ones ending in networks of enterprise activities which are connected by the behavioural rule sets. It is this network of enterprise activities which represent the business process model to be used in the operational support.
Processes are triggered by events (e.g., customer order arrival, timer, etc.) and completed by producing their end result(s). Producing the end-result may start another process (e.g., shipment) or be used to synchronise other processes. Processes can start one another demanding sub-results to be produced, which are used in the course of their own processing. The calling process may have to go into a wait state or may pre-schedule the sub-result.

Fig. 4 shows a simplified example of the CIMOSA modelling methodology. Having determined the business domain to be modelled (e.g., order processing) and its relationships with its environment (e.g., customer, supplier), the individual, but communicating business processes (P-1/3) and their activities (for P-2=EA1/4) are identified.


Fig. 4

The information items used in the model are identified as inputs and outputs of the enterprise activities (Fig. 4, lower part for EA4 only). The inputs can define the things to be processed (material/parts, information), the resources needed for the processing and control information for the processing by the particular activity. Outputs will be the result and the ending statuses of both the activity and the resources. The information attached to the ending status may be used in monitoring processes for administrative purposes or for exception handling. Inputs and outputs are aspects of enterprise objects which are represented in the information part of the enterprise model.

The BRS identifies the conditions under which the different activities will be started. Business processes are started by events (e.g., orders), however, the actual start activity may be different for different events (e.g., Shop Floor Order aEA1 and Shop Floor Order bEA3). Process results may also be produced by different activities and at different times (EA2Product a and EA4Product b). Events and results will be exchanged with external partners (customers or suppliers) or between different business processes.

 

(Kosanke, K., et al, CIMOSA: enterprise engineering and integration)


No comments:

Post a Comment