An Approach to Designing Safety Critical Systems using the Unified Modelling Language
Richard Hawkins, Ian Toyn, Iain Bate
Department of Computer Science
The University of York
Heslington, York
YO10 5DD, UK
{richard.hawkins, ian.toyn, iain.bate}@https://www.doczj.com/doc/db4853423.html,
Abstract. In this paper an approach to using the UML for developing safety
critical systems is presented. We describe how safety analysis may be
performed on a UML system model and how this analysis can derive safety
requirements for classes in the system. We show how these requirements can be
expressed in the form of safety contracts using the OCL. This makes it possible
to reason about the safety of individual elements of the UML model and thus
makes it easier to safely change the UML design, as well as facilitating
maintenance and reuse of classes or components in the system. A tool is also
described which has been developed to automate some aspects of this analysis.
1 Introduction
There is increasing interest in the use of an Object Oriented (OO) approach for developing safety critical systems. OO systems have improved maintainability due to encapsulation, high cohesion and low coupling, and the facility for reuse through inheritance and design patterns. These benefits could bring potentially large savings in terms of time and cost for developers of safety critical systems. However they also raise specific challenges which must be addressed if the full advantage of these OO features are to be realised for safety critical systems. To realise these benefits requires an ability to reason about the safety of individual classes or components in a system. This requires firstly that safety and hazard analysis be successfully performed on OO designs.
The Unified Modelling Language (UML) has become a de-facto standard for modelling OO systems and is widely used throughout industry. In this paper we initially look at performing hazard analysis of UML models. Moreover, however, most existing safety analysis techniques tend to decompose hazards in a functional manner. It is therefore difficult to reason about the safety of individual classes or components. If the benefits discussed earlier are to be realised, these existing techniques must be adapted such that the required results are obtained. Therefore we go on to look at how safety requirements may be captured in the form of safety contracts. These safety contracts can be specified using the Object Constraint
Language (OCL) and incorporated into the UML model of the system. This could contribute towards the development of a safety critical profile for UML. We show how the safety contracts can be generated through analysis of different aspects of the UML model, covering functional, timing and value behaviours.
2 System Safety Analysis
Leveson provides us with the following definitions [1]. Safety is the freedom from accidents or loss. Safety critical systems are systems which have a direct influence on the safety of their users and the public. A hazard is a state or set of conditions of a system that, together with other conditions in the environment of the system, will lead inevitably to an accident. The primary concern of system safety analysis is the management of hazards: their identification, evaluation, elimination, and control through analysis, design and management procedures. One aspect that distinguishes system safety from other approaches to safety is its primary emphasis on the early identification and classification of hazards so that corrective action can be taken to eliminate or minimize those hazards as part of the design process. The system safety process culminates in a safety case being produced that gathers all the necessary evidence to justify the system is safe.
The system safety analysis process can be basically split into the following steps: ? Hazard identification – This step identifies the potential hazards in the proposed system.
? Risk assessment – This examines each of the identified hazards to determine how much of a threat they pose. This assists in deciding the
steps required to reduce the risks to acceptable levels. Many initial safety
requirements are set at this stage.
? Preliminary system safety assessment (PSSA) – This phase is concerned with ensuring that a proposed design can meet its safety requirements and
also with refining these safety requirements as necessary
? System safety assessment – This stage is concerned with producing the evidence that demonstrates the safety requirements have been met by the
implementation.
? Safety case delivery – This involves producing a comprehensive and defensible argument that the system is safe to use in a given context. The
analysis performed as part of the PSSA stage will form part of this
argument.
In this paper we are primarily concerned with the PSSA. This is very closely linked with design activities. A key part of this is the identification of specific derived safety requirements to guide the detailed design of the system. The majority of the safety analysis techniques used in PSSA are deductive. This means that they investigate possible causes of a specific hazard or condition, starting from system level hazards and requirements identified during the hazard identification phase. The majority of techniques used for PSSA tend to decompose hazards functionally. System level hazards are identified, and for each, functional failures which may contribute to that hazard are elicited.
For a functionally decomposed system it is much easier than in an OO system to allocate a functional failure to the failure of a system component. This is because there is often a direct mapping between a functional failure and a subsystem. An OO design is not decomposed functionally, but rather into classes and objects. The functionality of the system is realised by many objects collaborating through message passing to achieve a system function. Therefore a functional failure will not map easily onto a single element of the design. In theory it would be possible to put all functionality into just one class and to apply standard safety analysis techniques. In doing this however, all advantages of adopting an OO approach would be lost. It is important therefore, for OO systems and indeed for UML system models that existing techniques can be adapted such that failures can be allocated between classes.
Our approach achieves this by allocating derived safety requirements to individual classes and controlling the interactions between classes through the use of contracts. This allows the impact of changes to be understood. An appropriate allocation of constraints would also allow better support for change in that change would be contained within a class or within a small hierarchy of classes. Other work looks at this in more detail.
3 Safety Analysis for UML
There have been attempts to adapt safety analysis techniques to apply them to UML. In [2], Lano et al examine how Hazard and Operability Studies (HAZOP) can be adapted to UML. HAZOP is a predictive safety analysis technique which uses a set of guidewords to consider the behaviour of ‘flows’ between system components. Lano et al take the standard guidewords for HAZOP defined in Defence Standard 00-58 [3] and reinterpret them such that they are applicable to different views of the UML model. For example, when considering state transition diagrams, the ‘flow’ is taken to be the transition and the guidewords are interpreted accordingly. Similarly, for class diagrams ‘flows’ are taken to be relationships. This is a very useful approach to analysing failures, however it would demand that the technique be applied to every class, attribute, state transition and interaction in the system to be effective. Even for a fairly small system this could be prohibitively time consuming.
Nowicki and Gorski have also developed analysis based largely around state charts. In [4], three methods are introduced. The first method, detailed in [5] centres around the development of a hazard model, which explicitly models safe and unsafe states and the transitions between these states. Reachability analysis can then be used to check if the hazardous state is reachable. This method assumes that the system and environment are reliable in the sense that they behave as specified. The second method [6] accepts that this assumption isn’t always valid as objects are exposed to random failures and the environment can violate assumptions made about it. This method provides a set of templates of faulty behaviour, which are deviations from the normal behaviour of the object. The templates consider possible faults in transitions and are applied to the state chart of the object under consideration. This generates a state chart for an ‘unreliable object’. Reachability analysis is then performed to see if a hazard can occur for the unreliable object. Whereas the first two methods were
concerned with analysing the system design, the final method aims to strengthen the safety guarantees of the system by enriching the system with a ‘safety monitor’ object. This is of less interest here. It is the second method which is perhaps most useful. There are certain weaknesses, particularly in identifying which objects to apply the templates to. Again, applying them to all objects in the system would be potentially very time consuming. It is also unclear how hazardous states are correctly identified.
In the remainder of this section we take some of the ideas discussed above and incorporate other techniques such as Fault Tree Analysis (FTA) to produce a more focussed approach to analysing UML models such that safety requirements can be derived for classes in the system in the form of safety contracts. Safety contracts constrain the design of the interactions which occur between objects, and hence can ensure system behaviour is safe. The properties of an interaction that we are interested in from a safety perspective are function, timing and value. Analysis of each of these aspects results in requirements which are included in the safety contract. Safety is a system property and therefore, the analysis process will begin with the consideration of a system level hazard.
3.1 Functional Aspects
Fig. 1 – Class Diagram for Part of a Stores Management System
To illustrate the analysis we use an example of a highly simplified aircraft Stores Management System (SMS). In the context of an aircraft, a store could be such things as a weapon or a fuel tank. These are connected to the aircraft via stations on the wings. The UML class diagram for this system is shown in figure 1. The initial hazard identification process performed on the SMS identified a number of general system hazards including:
? Inadvertent release of store
? Release of store whilst on the ground
? Inadequate temporal separation of store releases
? Unbalanced stores configuration
Fig. 2. UML Sequence Diagram for a Normal Operation Scenario. Fig. 3. Simplified Fault Tree for the Release of Store Whilst on the Ground
For all hazards identified it is necessary to perform analysis to identify how the hazard may be brought about. For this example we will look solely at the release of store whilst on the ground hazard. A UML sequence diagram is developed to illustrate the dynamic behaviour of the system for the relevant normal operation scenario. This can be seen in figure 2. A fault tree is constructed using system information collected from the UML diagrams and domain knowledge. Fault Tree Analysis (FTA) represents graphically the combination of events and conditions which contribute to a single undesirable event. Starting from the top event, the immediate causes of that event are identified. The manner in which these causes contribute to the event is expressed with the use of logic gates (basically AND and OR). This continues down the tree until the tree consists entirely of basic events, i.e. events which cannot be decomposed further, or until the desired level of detail has been reached. The fault tree in figure 3 shows the faults that can occur to bring about the top event “Release
of store whilst on ground”. It should be noted that WOW is ‘Weight on Wheels’, used to indicate when the aircraft is on the ground.
It is possible to relate leaf nodes (undeveloped failure events) in the fault tree, represented by diamonds, to classes in the system. For example the ‘WOW not checked by store’ event can be associated with the Store class in the system design. Not all leaf nodes in the fault tree will relate to classes in the system design. Of the six leaf nodes in figure 3, three can be related to classes in the system design. For example ‘Failure of WOW sensor’ cannot be attributed to a class, since the WOW sensor is not part of the Stores Management System. For the three leaf nodes identified as related to the SMS’ classes, the information from the fault tree can be used to generate a definition of the hazardous behaviour of the system. This information is recorded in a table as shown in table 1.
Table 1. Table of hazardous class behaviour
Hazardous event (from FT) Class Interaction Role Hazardous
class
behaviour
WOW not checked by store Store checkWOW() client Stores_Manager.checkWOW()
call not made as required
Store releases anyway Store release() supplier Store moves to released state
inappropriately
SM fails to respond to WOW signal Stores
Manager
WOW(true) –
signal
supplier Stores_Manager fails to move
to WOW state
In this table, the hazardous event field is the event identified in the fault tree. The class field is the class with which that event is associated. The interaction is the operation identified from the interaction diagram as corresponding to this event. The role is that played by the class in that interaction (either client or supplier of that operation call), and the hazardous class behaviour is that which would be exhibited by an instance of the class to bring about the hazardous event.
3.1.1 Analysing State Charts
We have now derived hazardous conditions for classes in the system. It is therefore possible to start constructing safety requirements and safety contracts for these classes. However to identify more detailed derived safety requirements it is necessary to understand how the class may behave such that these conditions can occur. This can be done by studying the state charts of these classes. For the purposes of this example we will consider just the Store class. A simple state chart has been developed for this and is shown in figure 4. A store may be jettisoned or released, jettison is a special case of release when a store is in a ‘safe’ state (e.g. dropping an unarmed weapon). The hazardous class behaviour for the Store class taken from table 1 can be summarised as:
? State = release ^ ?checkWOW
? State = release ^ WOW = true
Now that hazardous states have been defined it is possible to apply the ideas of Gorski and Nowicki discussed earlier [6]. Firstly it is assumed that the system behaves as specified in the design, that is that the class exhibits no faulty behaviour. In this simple example it can be seen from examining the state chart that this design does not exhibit any of the hazardous behaviour defined above. Checking that a proposed design does not exhibit hazardous behaviour can be achieved using a reachability analysis tool. The effects on the safety of the system if an object were to behave in an unexpected manner, that is to behave in a way other than that specified in the design due to mistakes in implementation, must also be investigated. To do this we mutate the transitions in the state chart [6]. Transitions in a state chart are of the general form event[condition]/action. The event triggers the state transition, the condition is a Boolean expression which must evaluate to true for the transition to occur and the action is triggered when the transition fires. Transitions may have any, all, or none of these elements. In order to identify possible faulty behaviours for the transitions we can apply guidewords to each of the elements of the relevant transitions. In order to be able to simulate these faulty behaviours, extra transitions must be added to represent these deviations in the state chart.Applying the guidewords omission, commission and value to each of the elements results in five distinct transitions:
1 - e[c] self-transition – event or condition is ignored (omission)
2 - not e[c] / a – event spuriously generated or action performed without initiating
event (commission)
3 - e[not c] / a – condition taken as true when false (value)
4 - e[c] – action is ignored (omission)
5 - e[c] / b (where b is an action other than a of the initiator object) – wrong action
performed (value)
For each of the transitions in the state chart relevant to the hazardous behaviour, these five extra transitions are added to the diagram to simulate faulty behaviour. The results of this can be seen in figure 5. The transitions between the unselected and selected states have not been included as they are not relevant to the hazardous behaviour we are interested in. It is now possible to identify if any of the faulty behaviours are unsafe. These are the faulty behaviours that can lead to the hazardous object behaviour which was defined previously.
The faulty transitions that could lead to the hazard ‘Release of store whilst on the ground’ can now be analysed. The results of this are shown below.
A1. release – Not Hazardous
A2. not release / check WOW - Not Hazardous
A4. release – Hazardous – WOW is not checked but class may enter release state A5. release / remove store – Not Hazardous
B1. [WOW=false] – Not Hazardous
B3. [WOW=true] – Hazardous – class enters release state when WOW is true
C1. [WOW=true] - Not Hazardous
C3. [WOW=false] - Not Hazardous
Fig. 4. State Chart for Store Class Fig. 5. Mutated State Chart Showing Faulty
Transitions
It is possible for more complex system designs to use an automation tool to generate the mutated transitions and to check which of these transitions may bring about the hazardous condition. Such a tool is under development at the University of York and is discussed in section 5. Although most of the faulty transitions identified through this method are not hazardous (i.e. will not contribute to the system hazard) they still result in incorrect operation. In defining a safety contract we are only interested however in constraining the hazardous behaviour and not all correct behaviour. There is now sufficient information about the intended and faulty behaviour of the class to begin to construct a contract for operations which may contribute to the system hazard. We look at constructing these contracts in section 4. 3.2 Timing Aspects
Although a large part of the safety requirements generated for any given system will be functional in nature, it is important to also consider the impact of non-functional properties on the safety of the system. Firstly the timing of the interactions is investigated. This analysis process hinges on identifying deadlines, separations and priorities for tasks performed by the system. A task is an encapsulated sequence of operations that executes independently of other tasks [7]. Therefore a task will consist of a number of interactions between classes in the system. Again the analysis begins with the identified system level hazards and at this point we focus on the normal scenario for releasing a store as shown in the sequence diagram in figure 2. This scenario can be broken into the following tasks:
? Select store – This task begins with the pilot choosing a store and ends with that store being selected
? Release store – This task begins with the pilot requesting a release and ends with the store being removed from its station. This task also includes a
subtask of checking WOW.
The analysis involves investigating the effect of deviations on the tasks that are performed to identify which of these deviations may contribute to a system hazard. The deviations considered are tasks occurring too quickly or too slowly and early or late. Early and late correspond to a task occurring too soon or too long after the previous task or event. The result of applying these deviations to the identified tasks is shown in table 2.
Table 2 – The effects of timeliness of tasks on system hazards
Task Deviation
Effect
Quick No safety consequence (positive effect) – It is desirable that the
selection of the correct store occur as quickly as possible
Slow Potential safety impact – Delays in selecting the appropriate
store for release may delay release
Early Select Store
Late This task is triggered by the pilot who’s decision to select a store will impact safety only if incorrect store is chosen
Quick No safety consequence (positive effect) – It is desirable that the
store be released as quickly as possible when requested
Slow Potential safety impact – A delay in releasing a store could be
hazardous to the aircraft under certain circumstances
Early Hazardous – A weapon released too soon after a previous
weapon could be catastrophic
Release Store
Late No safety consequence
Those tasks whose timeliness may have an impact on the safety of the system have now been identified and constraints must now be specified for these tasks. For quick and slow interactions it is necessary to constrain the response time of the task. If necessary a minimum response time and a maximum response time, or deadline can be specified for a task. A minimum response time will be specified for those tasks where too quick is identified as being hazardous and a deadline is specified for those where too slow could be hazardous. For tasks where early or late may be hazardous, minimum and maximum separations respectively between the completion of one task and the triggering of the next or between an event and the triggering of a task must be specified. These constraints can be used to define a safe scenario of tasks.
Domain knowledge is used to place the following requirements on the tasks identified above as being hazardous or potentially hazardous. It should be noted that this analysis is not trying to produce accurate estimates of execution times for operations or transactions, but to specify the minimum requirements for a safe system. Requirements should therefore have as much tolerance as possible whilst still constraining the task sufficiently to ensure it is safe. This will allow maximum flexibility to the implemented system. In [8] we presented an approach and framework for identifying, in control systems, an appropriate and valid set of timing requirements, and their corresponding control parameters. The approach is based on decomposing the systems objectives to a number of design choices and assessment criteria. Each design choice can be evaluated using a combination of static analysis and simulation. Heuristic search techniques can then be used to search the design space for the design solution considered most appropriate. The figures given below are for illustration purposes only.
? Select store – From pilot choosing a store to that store being selected should be no longer than 200ms – Deadline = 200ms
? Release store – The minimum permissible time between store releases will vary depending on the type of store being released. For this example we will
specify – Min Separation = 100ms
? Release store – The time from the pilot requesting a store release to that store’s removal from the station should not exceed 50ms – Deadline = 50ms Up to this point only the normal scenario has been identified. A scenario is a sequence of actions that illustrates the execution of a use case. Therefore a normal scenario simply represents the normal or expected sequence of actions which occurs for a particular use case, in this example releasing a store. When considering safety however it is important to consider alternative scenarios which may occur as these could potentially be hazardous, but may also lead to a requirement for extra timing constraints. In order to illustrate the scenarios clearly, the UML notation of activity diagrams can be used to show the different sequences of tasks which may realise the use case. Although activity states in an activity diagram are normally used to model a step in the execution of a procedure, here each activity state is used to represent a task or sub-task. We have found activity diagrams to be particularly suited to this application as they emphasize the sequential and concurrent nature of the tasks in a scenario. However, it is acknowledged that sequence diagrams could also potentially be adapted for this purpose. The alternative scenarios can be identified by omitting tasks from the normal scenario, adding in extra tasks (i.e. repetition of existing tasks), tasks occurring concurrently with other tasks or tasks occurring in an alternate order. It is necessary to identify if any of the alternative scenarios identified could be hazardous. That is to say that they could provide an additional contribution to the hazard. These scenarios could also necessitate additional timing requirements, which will form part of the safety contract (see section 4).
3.3 Value Aspects
The data represented in the system can also contribute to system hazards if important data attributes are incorrect. It is important for each system hazard to identify which data attributes are critical. These critical data items must be constrained to ensure that they won’t contribute to the hazard. It is possible to take advantage of the information hiding principle inherent in OO when trying to place constraints. If the attributes of a class are private, it is only possible for them to be manipulated by operations provided by the class. It is therefore possible to protect the accuracy of data items by constraining the interactions that may manipulate that data. It is therefore important for safety critical systems that attributes of classes are declared as private such that they may be constrained in this manner.
For the system hazard ‘incorrect store released’ it can be identified (through a fault tree) that the pilot selecting an incorrect store, or the wrong store information being displayed to the pilot could cause incorrect store selection. This would be caused by the incorrect store being associated with a particular station. The critical attributes here (as identified from the class diagram in figure 2) are the station ID and store ID, which are associated through the location class. The only operation specified in this system design which can manipulate this data is the addStore() operation of the station class. When this operation is called on a station, the store ID passed as a
parameter is associated with the station through the creation of a location object. By constructing constraints it is possible to assure the store ID being passed is correct.
The nature of constraints can only be properly specified with a great deal of understanding about the system under consideration. Even more so than with functional and timing aspects of the system, the data within a system is very dependant on domain knowledge for deriving effective safety requirements
4 Specifying Safety Contracts
Once the safety requirements for the classes in the system have been derived it is necessary to specify them in a useful and meaningful way. There are a myriad of techniques such as Douglass’ real-time annotations [9] suitable for specifying constraints in UML. In this work we have chosen to use OCL [10], which is a constraint language compatible with UML. The pre- and post-condition constraints from OCL can be used as the basis for safety contracts on operations. An OCL expression for an operation can be expressed as follows:
context Typename::opName(param1 : Type1,…):ReturnType pre: param1 > …
post: result = …
The constraints expressed in this manner are all requirements on static aspects of the system. As can be seen with the example in section 2, it is often necessary from a safety perspective to express that events have happened or will happen, that signals have or will be sent, or that operations are or will be called. An extension to OCL then known as an action clause was proposed by Kleppe and Warmer [11] to address this problem. This has formed part of the response to the UML 2.0 OCL request for proposals submission where it has become known as a message expression [12]. To specify that communication has taken place, the hasSent (^) operator is used. A simple example is given below:
context Subject::hasChanged()
post: observer ^ update(12,14)
The post condition here results in true if an update message with arguments 12 and 14 was sent to observer during the execution of the hasChanged() operation. Update() is either an operation that is defined in the class of observer, or it is a signal specified in the UML model. The arguments of the message expression must conform to the parameters of the operation/signal definition. Messages in OCL are particularly useful for describing the functional aspects of the safety requirements. From the results of the analysis carried out in the example, a safety contract can be defined for the store class which restricts the hazardous behaviour. This safety contract is shown below: context Store ::release()
pre: none
post: WOW=false
and
Stores_Manager ^ checkWOW()
A further limitation of OCL is that no way is provided for representing constraints over the dynamic behavior of a system. Again an extension to OCL has been proposed for modeling real-time systems [13]. This provides a mechanism for representing deadlines and delays. Deadlines for operations can be represented in the following manner:
context
Typename::operationName(param1:Type1,…):ReturnType
pre: …
post: Time.now <= Time.now@pre + timeLimit Where Time is a primitive data type that represents the global system time and timeLimit is a variable representing a time interval. In our examples we take the unit of time to be ms. The above constraint represents a maximum permissible execution time equal to timeLimit for the operation operationName().
Delays in reactions to signals or events can be represented in the following manner:
context
Typename::operationName(param1:Type1,…):ReturnType
pre: lastEvent.at + timeLimit >= Time.now
post: …
Where lastEvent.at is the arrival time of the last event. This represents a maximum delay equal to timeLimit for reaction to the lastEvent. The requirements derived for the timing aspects of the store class can thus also be represented as part of the contract. The safety contract for the store classs of the SMS would therefore be of the form:
context Store ::release()
pre: previous_release.at + 100 <= Time.now
post: WOW=false
and
Time.now <= Time.now@pre + 50
and
Stores_Manager ^ checkWOW()
By using OCL to specify contracts in this way the safety requirements on each class in the system design are explicit. For all our case studies, OCL with the extensions described has proved suitably expressive. If necessary however, other constraint languages or extensions could be considered. To ensure it will not impact on the safety of the system, the class must meet the set of safety requirements consisting of all preconditions of interactions for which it is the client, and all post conditions of interactions for which it is the supplier. To know that a system will be safe it is necessary to show that the complete set of safety requirements are met. Specifying contracts in this way also makes it easier to deal safely with maintenance, change, and reuse. This is discussed more thoroughly in [14].
5 Tool Support
Our tool support, as developed to date addresses the analysis discussed in section 3.1.1. Tool support for this part of the analysis is particularly important given its potential complexity for real systems. The tools developed provide assistance in a number of ways. They can identify sequences of transitions that could lead to an identified hazard. The tools are also capable of generating mutations of transitions which may arise due to mistakes in implementation. It is possible to perform these in combination to identify which mistakes in implementation could lead to an identified hazard. The tools can also be used for test data generation by identifying what input values would trigger a transition, and what output values would result from that transition and inputs. This allows us to create test cases for any of the hazardous potential mistakes in our implementation. Before any of this can be done however it is first necessary to check that the state chart under consideration uses only notations that are analysable by the tools, and to formalise the state chart ready for analysis.
5.1 Well-formedness and Formalisation
The tool first checks that the state chart provided is analysable, that is that the state chart is well-formed. If this is the case then the state chart is translated into an ISO standard Z representation [15]. Both of these steps are fully automated. Once the tool has been initiated with the state chart design no user intervention is necessary. The rest of the toolset works from the resulting Z representation. This should ensure that the analysis is less dependant on any particular state chart dialect. We currently cope with Statemate and Stateflow. Each of the transitions in the state chart is represented by a Z schema. The inputs and outputs of the state charts become inputs and outputs of the schema. The labels on transitions become predicates over these inputs and outputs.
5.2 Mutant Generation
In section 3.1.1 it was shown how extra transitions can be added to the state chart to simulate faulty behaviour. These extra transitions are referred to in the toolset as mutant transitions. The five basic cases in 3.1.1 are the basis for the mutant generation by the tool.
1 - e[c] self-transition – This involves changing the destination state to be the same as the source state and dropping the action.
2 - not e[c] / a and
3 - e[not c] / a – These are generalised to negate any conjunct of the e[c] trigger, and also to negate the entire trigger. Where the trigger involves ordering relations, each can be mutated to use a different relational operator, e.g. < becomes <=.
4 - e[c] – This involves deleting the action. If the action is a sequential composition, further mutants are generated by deleting one of those actions.
5 - e[c] / b – This involves changing the actions. Where an action is the assignment of a Boolean, the Boolean assignment can be negated. Where an action is an
assignment of a number, the number assigned can be incremented/decremented, and any arithmetic operator can also be changed, e.g. + to –.
The tools generate all mutants that they can, for all transitions. The user merely initiates the mutant generation. It should be noted that using the tools allows many more mutants to be considered than would otherwise be feasible.
5.3 Hazard Detection
Section 3.1 illustrated the identification of hazards for a class in the system. In section 3.1.1 these were shown in a notation that is basically Z predicates, but which need declarations of the names to be legal Z, these were:
? State = release ^ ?checkWOW
? State = release ^ WOW = true
By writing them in a Z schema with inclusion of the state chart’s inputs and outputs, the identified hazards become available to the tools. This small and relatively simple step currently has to be done manually, but since it involves manipulation of Z could be automated. Hazard detection involves conjecturing whether a composition of transitions implies the hazard. The hazard might be implied never, sometimes or always. This can be done for the original state chart and for the mutant transitions. When composing only original transitions, sometimes is sufficient for concern. When composing transitions involving mutants, it may be preferable to focus on the always cases. The user chooses the maximum length of compositions to be considered, then the tools perform automatically. The cost increases rapidly with the number of alternative transitions exiting each state. Generating a large number of mutants can also have a devastating effect on the cost of hazard detection. It would be possible to allow the user to limit the number of mutants generated by the tool in order to ensure hazard detection remained practical. This could be based on the complexity of the initial state chart and the severity of the resulting hazard. Further work may look at this.
5.4 Test Data Generation
Test data generation for a transition amounts to finding a binding that exists in the schema. This determines input and output values simultaneously. The solutions are written out in a form suitable as input to a test harness tool. The user has only to choose the transition for which to generate test data. This allows tests to be constructed to check for the existence in the implemented design of any of the hazardous mutant transitions identified previously by the toolset.
6 Conclusions and Future Work
In this paper we have outlined an approach to developing safety critical systems using UML. This is based on analysis of the UML system model. We have described with a simple example how this analysis may be carried out. We have also described a
tool for automating some aspects of this analysis. This analysis derives safety requirements for classes in the system. We have shown how these requirements can be expressed in the form of safety contracts using OCL. This approach makes it possible to reason about the safety of individual elements of the UML model and thus makes it easier to safely change the UML design, as well as facilitating maintenance and reuse of classes or components in the system.
Future work will focus on verification that a design will meet derived safety requirements arising from safety contracts, and deal with violation of conditions. We will also look at supporting traceability, particularly with a changing or evolving UML model. It will also be necessary to define safety arguments in support of this approach such that UML may be successfully adopted into safety critical domains.
The work presented in this paper was funded by BAE Systems through the DCSC, and by the EPSRC through the MATISSE project. A great deal of work on developing the toolset was carried out by Stuart Bass, an intern student at the University of York. References
1. Leveson, N., Safeware - System Safety and Computers. 1995: Addison-Wesley.
2. Lano, K., D. Clark, and K. Androutsopoulos, Safety and Security Analysis of Object
Oriented Models. Lecture Notes in Computer Science, 2002. 2434: p. 82 - 93.
3. MoD, Defence Standard 00-58: Hazop Studies on Systems Containing Programmable
Electronics. 1996: HMSO.
4. Nowicki, B. and J. Gorski, Object Oriented Safety Analysis of an Extra High Voltage
Substation Bay. Lecture Notes in Computer Science, 1998. 1516: p. 306-315.
5. Gorski, J. and B. Nowicki, Safety Analysis Based on Object-Oriented Modelling of Critical
Systems. Proc. SAFECOMP '96, 1996: p. 46 - 60.
6. Gorski, J. and B. Nowicki, Object Oriented Approach to Safety Analysis. Proc. ENCRESS
'95, 1995: p. 338-350.
7. Douglass, B.P., Real-Time UML - Developing Efficient Objects for Embedded Systems.
1998: Addison-Wesley.
8. Bate, I., J. McDermid, and P. Nightingale, Establishing Timing Requirements for Control
Loops in Real-Time Systems. Journal of Microprocessors and Microsystems, 2003.
27(4): p. 159 - 169.
9. Douglass, B.P., Doing Hard Time - Developing Real-Time Systems with UML, Objects,
Frameworks, And Patterns. 1999: Addison-Wesley.
10.OMG, Object Constraint Language Specification, in Unified Modeling Language
Specification version 1.4. 2001, Object Management Group.
11. Kleppe, A. and J. Warmer, Extending OCL to Include Actions. Lecture Notes in Computer
Science, 2000. 1939: p. 440-450.
12. Warmer, J., et al., Response to the UML 2.0 OCL RfP - Revised Submission, Version 1.6.
2003, OMG.
13. Cengarle, M. and A. Knapp, Towards OCL/RT. Lecture Notes in Computer Science, 2002.
2391: p. 390-409.
14. Hawkins, R.D. and J. McDermid, Developing Safety Contracts for OO Systems. Proc. 21st
International System Safety Conference, 2003.
15. ISO, Information Technology - Z formal Specification Notation - Syntax, Type System and
Semantics. First Edition ed. 2002: ISO / IEC
检验科岗位职责 集团文件版本号：（M928-T898-M248-WU2669-I2896-DQ586-M1988）
4.14.3检验科岗位职责 检验科主任职责 一、负责本科的业务、教学、科研及行政管理工作。 二、负责组织本科业务技术建设规划、年度以工作计划和质量体系方案的制定、实施、检查和总结。 三、负责解决本科复杂、疑难的检验、诊断及仪器设备的使用等技术问题。审签重要的诊断报告。 四、负责本科的业务训练、人才培养和技术考核工作。安排进修、实习人员的培训，并担任教学工作。 五、督促检查本科人员履行各自的职责，认真执行规章制度及技术操作常规；进行医疗安全教育，严防事故、差错。 六、负责本科医德医风建设。提出考核、晋升、奖惩和培养使用的意见。 七、负责本科人员考核、绩效发放等工作。 八、完成医院交办的其它工作。 九、副主任协助主任完成以上工作。 检验科主任（副主任）技师职责 一、在科主任的领导下，负责本专业的业务、教学、科研和仪器设备的管理工作。 二、解决本科复杂、疑难的技术问题，并参加相应的诊断工作。 三、负责业务技术的训练和考核，担任教学工作，培养主管技师解决复杂技术问题的能力。 四、掌握本专业国内外信息，指导下级技术人员工展科研和引用新业务、新技术的工作，总结经验，撰写学术论文。 五、参加临床疑难病的会诊及讨论，负责疑难检验项目的检查与室内质控及室间质评工作。 检验科主管技师职责 一、在科主任领导下进行工作。 二、熟悉各种仪器的性能和使用方法，协同科主任制定技术操作规程和质量控制措施。负责仪器的调试、鉴定、操作和维修保养，解决较复杂、疑难的技术问题，参加相应的诊断工作。 三、担任教学业工作，指导和培养技师解决较疑难技术问题的能力，担任进修、实习人员的培训，并负责其技术考核。
LED的光色组合照明系统推动了照明理念的变革，LED光源的显色性问题引起国际上广泛争议，CRI不能表示白光LED的显色范围。美国提出的CQS、GAI等评价方法也只是对CRI 的修修补补。人眼的视觉认知特性与非视觉感知决定了对照明质与量的要求，应根据LED 高色饱和度产生的视觉效果对照明、物体色和固有色有更加深刻的理解，探索采用高色饱和度LED组合照明系统，满足人们对科学、安全、健康、舒适性照明的需求。 前言 LED产业技术发展迅速，发光效率160lm/w的产品已面市，高质量的白光——显色指数CRI在90以上，色温3000K，100lm/w以上的光源已大批量生产，LED进入功能性照明的时代已来临。 LED高色饱和度的特性，可实现数字化、智能化、网络化的多光谱组合调控，能够满足不同视觉作业和功能性照明的需求。而基于传统普朗克黑体辐射理论形成的色温、显色指数、色差修正等照明国际标准，与使用高色饱度LED组合光源的视觉认知与非视觉感知效果相差较大。实践表明，这引起物理光度学、物理色度学与目视光度学、目视色度学的差距拉大。也使得光度学、色度学、测量学、色彩工程学等受到严重的挑战，引发照明理论的创新。以下是我们提出高色饱和度LED色光组合照明引起国际争议的问题，探讨高色饱和度LED 组合照明将成为照明的新亮点、新热点。 一、对照明本质的理解 人工照明是光源系统、被照物体和观察者三者之间联动作用的综合效应。LED光源可发出色饱和度高的单色光，多种色光的组合使被照物体更加鲜艳夺目，对人的生理、心理产生非同寻常的影响。我们认为照明是多种学科技术交叉的系统工程。理对物的解释是科学，情对物的表达是艺术，情与理的结合是心理，照明的本质是物、理、情的结合，如图1所示。 目前所有照明理论和标准大都局限和定位于视看要求，对于生物学和心理学的效应和要求还顾及不多。丰富多彩的LED照明系统使“光与健康”的命题空前活跃，国际上已开过多次高水平的研讨会，包括医学家、建筑师、照明专家共同从正面研讨发挥LED照明系统的潜能。 图1. 照明的本质是物、理、情的结合
检验科工作职责 -标准化文件发布号：（9556-EUATWK-MWUB-WUNN-INNUL-DDQTY-KII
检验科查对制度 一、建立健全查对制度，杜绝医疗事故，减少差错发生。 二、每次检验，检验师应对结果进行复核，并签上姓名。遇疑难问题，应及时报告科主任。 三、采集标本时： 1、门诊病人：认真查对科别、姓名、性别、年龄、检测项目、标本（质、量）。 2、住院病人：认真查对科别、住院号、床号、姓名、性别、检测项目、标本（质、量），同一病人，多张申请单时，认真查对各申请单的临床资料是否一致。 四、检验时，认真查对仪器性能、试剂质量、检验项目与标本是否相符。 五、检验后，认真查对检验目的、结果、是否缺项等。 六、发报告单时，认真查对科别、姓名及检验项目。 七、血型及输血检验时，认真查对病人姓名、性别，标本、血袋编号、标签是否完整，标本和诊断血清是否符合要求，献血员姓名，血型、Rh血型及血交叉试验结果，血袋是否有破损及血液质量。试验结果除肉眼观察外，必须用显微镜观察结果，以防弱凝集遗漏。复核者应认真核
对一次标签、血型、Rh血型及交叉试验结果后，签上核对者姓名。 检验标本管理制度 一、标本一律凭单采集，做好五查五对（科别、床号、姓名、性别、检验项目），临床科室送的标本要核对检验单、检查项目和标本采集是否符合要求。 二、检验标本分类进入各项检测程序，并严格做好编号和核对，缓检标本应核对后妥善保存。 三、检验后的标本应按规定，根据不同要求和条件限时保留备查，特殊标本特殊保存。 四、凡有传染性的标本，应按传染性标本管理规定须经灭菌处理后才能弃去。 差错事故登记报告制度 一、严格执行检验工作查对制度，包括：采集，收集标本、化验单的科别、床号、姓名、检验目的、检验标本的质量和量；检验时的项目、所用的试剂、编号；检验结束时的检验结果、登记；发报告时的科别等。 二、要做过细的工作，严防检验标本丢失或损坏，尤其是脑脊液、胸腹水液等重要标本，收到后应立即登记并检验，防止漏检、错检；生化检验标本验后应保留24小
4.14.3检验科岗位职责 检验科主任职责 一、负责本科的业务、教学、科研及行政管理工作。 二、负责组织本科业务技术建设规划、年度以工作计划和质量体系方案的制定、实施、检查和总结。 三、负责解决本科复杂、疑难的检验、诊断及仪器设备的使用等技术问题。审签重要的诊断报告。 四、负责本科的业务训练、人才培养和技术考核工作。安排进修、实习人员的培训，并担任教学工作。 五、督促检查本科人员履行各自的职责，认真执行规章制度及技术操作常规；进行医疗安全教育，严防事故、差错。 六、负责本科医德医风建设。提出考核、晋升、奖惩和培养使用的意见。 七、负责本科人员考核、绩效发放等工作。 八、完成医院交办的其它工作。 九、副主任协助主任完成以上工作。 检验科主任（副主任）技师职责 一、在科主任的领导下，负责本专业的业务、教学、科研和仪器设备的管理工作。 二、解决本科复杂、疑难的技术问题，并参加相应的诊断工作。 三、负责业务技术的训练和考核，担任教学工作，培养主管技师解决复杂技术问题的能力。 四、掌握本专业国内外信息，指导下级技术人员工展科研和引用新业务、新技术的工作，总结经验，撰写学术论文。 五、参加临床疑难病的会诊及讨论，负责疑难检验项目的检查与室内质控及室间质评工作。 检验科主管技师职责 一、在科主任领导下进行工作。 二、熟悉各种仪器的性能和使用方法，协同科主任制定技术操作规程和质量控制措施。负责仪器的调试、鉴定、操作和维修保养，解决较复杂、疑难的技术问题，参加相应的诊断工作。 三、担任教学业工作，指导和培养技师解决较疑难技术问题的能力，担任进修、实习人员的培训，并负责其技术考核。 四、了解国内外本专业信息，应用先进技术，开展科研和引用新精力、新技术。总结经验，撰写学术论文。 五、负责疑难项目的检验及报告的审签，参加临床病例的讨论。
北京调频电台频率表 城市频率电台 北京 87.6 北京人民广播电台文艺台 北京 88.2 中国国际广播电台EasyFM 北京 88.7 中国国际广播电台 北京 90.0 中央人民广播电台第三套节目文艺调频北京 91.5 中国国际广播电台EasyFM 北京 96.6 中央人民广播电台第二套节目经济频道北京 97.4 北京人民广播电台音乐台 北京 99.6 中央人民广播电台第二套节目 北京 101.8 中央人民广播电台第四套节目民族广播北京 103.9 北京人民广播电台交通台 北京 106.1 中央人民广播电台第一套节目综合频道上海 FM 107.7 中央电台音乐之声（第三套） FM 105.7 上海电台交通频率（AM648） FM 104.5 东广新闻台（东方广播电台） FM 103.7 魅力103（东方电台流行音乐频率） FM 101.7 动感101（东方电台流行音乐频率） FM 100.9 松江电台（郊区电台）（有严重杂音）FM 99.0 中央电台中国之声（第一套） FM 98.1 东方明珠移动电视MMTV（电视伴音）
FM 97.7 第一财经广播频率（东方电台财经频率） FM 96.8 开心调频（上海电台文艺频率） FM 96.2 宝山电台（郊区电台）（有严重杂音） FM 94.7 经典947（东方电台经典音乐频率） FM 93.4 990新闻频率（上海人民广播电台） FM 92.4 海上戏剧（上海电台戏剧频率） FM 91.4 中央电台经济之声（去年12月底开始在上海转播） FM 89.9 都市792（东方电台都市频率） FM 87.9 中国国际广播电台轻松调频（1月1日开始在上海转播）天津市区 FM87.80 天津人民广播电台·娱乐频率 FM91.1 天津人民广播电台·生活台 FM92.0 天津人民广播电台·滨海台 FM92.5 中央人民广播电台三台·音乐之声 FM97.2 天津人民广播电台·新闻台 FM98.0 中央人民广播电台二台·经济之声 FM99.0 天津人民广播电台·音乐台 FM101.4 天津人民广播电台·经济台 FM102.9 中央人民广播电台一台·中国之声 FM104.6 天津人民广播电台·文艺台 FM106.8 天津人民广播电台·交通台
检验科工作制度及人员岗位职责 检验科工作制度及人员岗位职责 检验报告双签字制度 一、检验完完毕，应认真核对所检测标本、检验结果是否与病人信息是否一致，无误后方可审核报告单。 二、报告单打印应字迹清晰、无错别字、内容准确规范，不得涂改，签名字迹要能辨认。 三、进修、实习人员和无临床检验资格证的人员无签字权，也不能代替有资格的老师签字。 四、检验报告由经验丰富、技术水平和业务能力较强的人员负责审核。 五、各专业组的报告每日应认真仔细审核，发现问题及时纠正;检验结果可疑时应及时进行复检并登记，不得草率发出。 检验科工作制度 1、认真执行检验技术操作规程，保证检验质量和安全，严格执行查对制度。 2、普通检验，一般应于当天发出报告，急诊检验应在检验单上注明“急”字，随采随验，及时发出报告，对不能及时检验的标本，要妥善保藏。标本不符合要求者，应重新采集。 3、认真核对检验结果，填写检验报告单，做好登记，签名发出。检验结果与临床不符或可疑时，应主动与临床医生联系，重新检查，发现检验项目以外的阳性结果，应主动报告。 4、检验结束后，要及时清理器材、容器，经清洗、干燥、灭菌后放 原处，污物及检查后标本妥善处理，防止污染。 5、采血必须坚持一人一针一管，严格无菌操作，防止交叉感染。
6、检验室应保持清洁整齐，认真执行检验仪器的规范操作规程，定期保养、检测仪器，不得使用不合格的试剂和设备。 7、建立并完善实验室质量保证体系，开展室内质量控制，参加室间质量评价活动。 8、配合临床医疗工作，开展新的检验项目和技术革新。 9、应制定检验后标本保留时间和条件，并按规定执行。废弃物处理应按国家有关规定执行。 10、加强检验室安全管理和防护，做好生物及化学危险品、防火等安全防护工作，遵守安全管理规章制度。 检验科试剂与校准品管理制度 1. 试剂与校准品采购与储存的管理 1.1成立试剂管理小组，协助科主任规范试剂管理过程中各个环节。并指定专人做好试剂的登记入库、出库、清点盘存、保管、报废等工作，做到账册实物相符。 1.2请购试剂必须填写请购单，科主任审查签字，然后交院采购中心统一采购。 1.3各实验室组长要按实际用量，以保证检验质量和节约开支为原则，有计划地请购试剂，以免造成试剂的无故浪费。 1.4试剂进货要做到来源渠道正规、货物优质、有批准文号、生产日期及供货单位加盖红印的《经营许可证》、《生产许可证》、《注册证》 复印件和法人委托书及业务员的身份证明。以上资料统一由采购中心专人登记保管。
光源的显色性与色温 光源对物体的显色能力称为显色性，是通过与同色温的参考或基准光源（白炽灯或太阳光）下物体外观颜色的比较。光所发射的光谱内容决定光源的光色，但同样光色可由许多，少数甚至仅仅两个单色的光波纵使而成，对各个颜色的显色性亦大不相同。相同光色的光源会有相异的光谱组成，光谱组成较广的光源较有可能提供较佳的显色品质。 当光源光谱中很少或缺乏物体在基准光源下所反射的主波时，会使颜色产生明显的色差(color shift)。色差程度愈大，光源对该色的显色性愈差。演色指数系数(Kaufman)仍为目前定义光源显色性评价的普遍方法 显色分两种 忠实显色：能正确表现物质本来的颜色需使用显色指数(Ra)高的光源，其数值接近100，显色性最好。 效果显色：要鲜明地强调特定色彩，表现美的生活可以利用加色的方法来加强显色效果。采用低色温光源照射，能使红色更加鲜艳；采用中等色温光源照射，使蓝色具有清凉感；采用高色温光源照射，使物体有冷的感觉。 显色指数与显色性的关系 当光源光谱中很少或缺乏物体在基准光源下所反射的主波时，会使颜色产生明显的color shift.色差程度越大，光源对该色的显色性越差。演色指数系数（Kau fman）仍为目前定义光源显色性评价的普遍方法。 白炽灯的显色指数定义为100，视为理想的基准光源。此系统以8种彩度中等的标准色样来检验，比较在测试光源下与在同色温的基准下此8色的偏离（Deviation）程度，以测量该光源的显色指数，取平均偏差值Ra20-100，以100为最高，平均色差越大，Rr值越低。低于20的光源通常不适于一般用途。 指数（Ra）等级显色性一般应用90-100 1A 优良需要色彩精确对比的场所 80-89 1B 需要色彩正确判断的场所 60-79 2 普通需要中等显色性的场所 40-59 3 对显色性的要求较低，色差较小的场所 20-39 4 较差对显色性无具体要求的场所 色温（CT-color temperature） 当光源所发出的光的颜色与黑体在某一温度下辐射的颜色相同时，黑体的温度就称为该光源的色温，用绝对温度K （kelvim）表示.黑体辐射理论是建立在热辐射基础上的，所以白炽灯一类的热辐射光源的光谱功率分布与黑体在可见区的光谱功率分布比较接近，都是连续光谱，用色温的概念完全可以描述这类光源的颜色特性。 相关色温（CCT-correlated color temperature） 当光源所发出的光的颜色与黑体在某一温度下辐射的颜色接近时，黑体的温度就称为该光源的相关色温，单位为K。由于气体放电光源一般为非连续光谱，与黑体辐射的连续光谱不能完全吻合，所以都采用相关色温来近似描述其颜色特性。色温（或相关色温）在3300K以下的光源，颜色偏红，给人一种温暖的感觉。色温超过5300K时，颜色偏兰，给人一种清冷的感觉。通常气温较高的地区，人们多采用色温高于4000K的光源，而气温较低的地区则多用4000K以下的光源。 色指数（Ra-color rendering index） 太阳光和白炽灯均辐射连续光谱，在可见光的波长（380nm-760nm）范围内，包含着红、橙、黄、绿、青、兰、紫等各种色光。物体在太阳光和白炽灯的照射下，显示出它的真实颜色，但当物体在非连续光谱的气体放电灯的照射下，颜色就会有不同程度的失真。我们把光源对物体真实颜色的呈现程度称为光源的显色性。为了对光源的显色性进行定量的评价，引入显色指数的概念。以标准光源为准，将其显色指数定为100，其余光源的显色指数均低于100。显色指数用Ra表示，Ra值越大，光源的显色性越好
义络公司医院 检验科工作制度及人员岗位职责 2012年10月
检验科工作制度、人员岗位职责目录 1、检验科工作制度 2、检验科质量管理制度 3、检验科查对制度 4、检验标本管理制度 5、检验报告单管理制度 6、检验科试剂管理制度 7、检验科安全管理制度 8、临床检验危急值报告制度 9、仪器管理制度 10、检验科档案管理制度 11、检验科登记制度 12、检验科卫生制度 13、检验科信息反馈制度 14、差错事故登记报告制度 15、检验科医院感染管理制度 16、检验室科废物处置管理规定 17、检验科人员职业安全防护措施 18、检验师职责
19、检验士职责 一、检验科工作制度 1、认真执行检验技术操作规程，保证检验质量和安全，严格执行查对制度。 2、普通检验，一般应于当天发出报告，急诊检验应在检验单上注明“急”字，随采随验，及时发出报告，对不能及时检验的标本，要妥善保藏。标本不符合要求者，应重新采集。 3、认真核对检验结果，填写检验报告单，做好登记，签名发出。检验结果与临床不符或可疑时，应主动与临床医生联系，重新检查，发现检验项目以外的阳性结果，应主动报告。 4、检验结束后，要及时清理器材、容器，经清洗、干燥、灭菌后放原处，污物及检查后标本妥善处理，防止污染。 5、采血必须坚持一人一针一管，严格无菌操作，防止交叉感染。 6、检验室应保持清洁整齐，认真执行检验仪器的规范操作规程，定期保养、检测仪器，不得使用不合格的试剂和设备。 7、建立并完善实验室质量保证体系，开展室内质量控制，参加室间质量评价活动。 8、配合临床医疗工作，开展新的检验项目和技术革新。
1.什么是显色指数？ 显色指数（Color Rendering Index），简称CRI。指物体用该光源照明和用标准光源（一般用正午时候的太阳光做标准光源）照明时，其颜色符合程度的量度，也就是颜色逼真的程度。显色指数用Ra表示，最好和最大的数值为100。具体灯具的Ra值可见如下： 白炽灯97，日光色荧光灯80-94，白色荧光灯80-90，卤钨灯80-90，高压汞灯22-51，高压钠灯20-30，金属卤化物灯60-65，LED可以达到97。 Lamp 白炽灯日光色荧光灯白色荧光灯卤钨灯高压汞灯高压钠灯金属卤化物灯LED Ra 97 80-94 80-90 80-90 22-51 20-30 60-65 97 显色指数有15种颜色，取前面八种常见颜色R1-R8的平均值，记做Ra。 2. LED的显色指数-strength LED灯具最大的优势就是节能环保，在商业照明和家居照明中能广泛取代现有的节能灯和卤素灯，光效的增加可以减少瓦数的使用，从而达到节能的目的。 目前在中国的厂家，基本标配是使用Ra>70的灯珠光源，而我们公司所用至少是Ra>80，如果客户要求也可提供Ra>90甚至Ra=97，目前市面上显指最高的可达到97，是西铁城的2W-20W。
虽然现今的LED显色指数已经能达到97，但也只有极少数的品牌可以做到，并且价格相对于卤素灯昂贵很多。并且各大厂家水准不一，为了降低成本甚至会使用60显指左右的灯珠，甚至是二次回收的灯珠。 4.LED的显色指数-Opportunity 各国鼓吹绿色经济，省电节能的LED自然受到政府的支持。一些国家的政府，比如美国和新西兰等，企业提供购买环保照明产品的津贴。LED是会逐步取代传统灯具，各大光源品牌例如西铁城、日亚等也每年增加研发资金，提高光色和光效。LED也有一些传统灯不能匹敌的功能，就是在细分市场上，如肉类照明、家居照明等，显色指数和光谱的配合能够使物体的颜色锦上添花，提高消费者的购买欲望，这是连自然光也做不到的。 5.LED的显色指数-Threats 人们普遍认为，传统灯显指能够达到100，最能体现物体的真实颜色。今天2015香港秋季展，钨丝灯有复辟的苗头，其造型精美，确实更加适合气氛温暖的场景，如餐厅，酒店，家居装饰。市面上的LED产品参差不齐，以次充好，不专业的知识误导客户，声称5500K的色温能够达到95显指。作为批发商、零售商、工程商对显色指数的知识甚少，这也难怪终端客户买不到好产品。 6.LED的显色指数-Questions 既然显色指数越高越好，那么显色指数又会受到什么影响呢？跟色温有关系吗？R1-R8的平均值是Ra，那R9-R15的数据对显色指数和光色又有什么影响呢？我们下节再说。 See you next week
色纯度 色纯度(Purity) 其为以主波长描述颜色时之辅助表示，以百分比计，定义为待测件色度坐标与E光源之色度坐标直线距离与E光源至该待测件主波长之光谱轨迹(SpectralLocus)色度坐标距离的百分比，纯度愈高，代表待测件的色度坐标愈接近其该主波长的光谱色，是以纯度愈高的待测件，愈适合以主波长描述其颜色特性，LED即是一例。 显色指数 光源对物体的显色能力称为显色性，是通过与同色温的参考或基准光源（白炽灯或画光）下物体外观颜色的比较。光所发射的光谱内容决定光源的光色，但同样光色可由许多，少数甚至仅仅两个单色的光波纵使而成，对各个颜色的显色性亦大不相同。相同光色的光源会有相异的光谱组成，光谱组成较广的光源较有可能提供较佳的显色品质。当光源光谱中很少或缺乏物体在基准光源下所反射的主波时，会使颜色产生明显的色差(color shift)。色差程度愈大，光源对该色的显色性愈差。演色指数系数(Kaufman)仍为目前定义光源显色性评价的普遍方法。 目录 编辑本段 忠实显色： 能正确表现物质本来的颜色需使用显色指数(Ra)高的光源，其数值接近100，显色性最好。
效果显色： 要鲜明地强调特定色彩，表现美的生活可以利用加色的方法来加强显色效果。采用低色温光源照射，能使红色更加鲜艳；采用中等色温光源照射，使蓝色具有清凉感；采用高色温光源照射，使物体有冷的感觉。 编辑本段 显色指数与显色性的关系 当光源光谱中很少或缺乏物体在基准光源下所反射的主波时，会使颜色产生明显的color shift.色差程度越大，光源对该色的显色性越差。演色指数系数（Kau fman）仍为目前定义光源显色性评价的普遍方法。 白炽灯的显色指数定义为100，视为理想的基准光源。此系统以8种彩度中等的标准色样来检验，比较在测试光源下与在同色温的基准下此8色的偏离（Deviation）程度，以测量该光源的显色指数，取平均偏差值Ra20-100，以100为最高，平均色差越大，Ra值越低。低于20的光源通常不适于一般用途。 指数（Ra）等级显色性一般应用 90-100 1A 优良需要色彩精确对比的场所 80-89 1B 需要色彩正确判断的场所 60-79 2 普通需要中等显色性的场所 40-59 3 对显色性的要求较低，色差较小的场所 20-39 4 较差对显色性无具体要求的场所 白炽灯的理论显色指数为100，但实际生活中的白炽灯种类繁多，应用也不同，所以其Ra值不是完全一致的。只能说是接近100，是显色性最好的灯具。具体灯具的Ra值可见下表所举。 光源显色指数Ra 白炽灯97 日光色荧光灯80-94 白色荧光灯75-85 暖白色荧光灯80-90 卤钨灯95-99 高压汞灯22-51 高压钠灯20-30 金属卤化物灯60-65 钠铊铟灯60-65 镝灯85以上
医院检验科岗位职责 1、医院检验科主任职责 一、负责本科的业务、教学、科研及行政管理工作。 二、负责组织本科业务技术建设规划、年度以工作计划和质量体系方案的制定、实施、检查和总结。 三、负责解决本科复杂、疑难的检验、诊断及仪器设备的使用等技术问题。审签重要的诊断报告。 四、负责本科的业务训练、人才培养和技术考核工作。安排进修、实习人员的培训，并担任教学工作。 五、督促检查本科人员履行各自的职责，认真执行规章制度及技术操作常规；进行医疗安全教育，严防事故、差错。 六、负责本科医德医风建设。提出考核、晋升、奖惩和培养使用的意见。 七、负责本科人员考核、绩效发放等工作。 八、完成医院交办的其它工作。 九、副主任协助主任完成以上工作。 2、医院检验科主任岗位职责 岗位职责： 1. 负责部门内部各岗位分工、人员调整、员工考核及日常管理等工作； 2. 负责实验室人员的招聘、培训、梯队建设等管理工作；
3. 负责各专业组内流程的优化，拟定本科工作规划并组织实施,检查并上报相关执行情况； 4. 完成医院交办的其他任务，配合相关人员开展工作； 5. 在保证检验质量的前提下，尽量节约开支，控制成本等。 3、检验科科主任岗位职责 1、在院长的领导下，负责全科各个专业检验、教学、科研和行政等方面的管理工作；确定科室的发展方向，建立质量控制体系，并定期审核质量体系，使之有效运行。 2、负责专业划分工作，审查各个专业组负责人的工作计划和实施方法，督促检查各个专业组负责人工作情况。 3、督促检查全科人员执行各项规规章制度和项目操作情况，考察各专业的检验质量。 4、督促科内人员正确使用与保管菌株、剧毒危险品和器材，审签药品和器材的请领，经常检查安全措施及执行情况，防止差错事故。 5、结合临床医疗，制定科研规划，不断引进国内外新成果、新技术和开展新项目。 6、督促检查各个专业的业务学习、技术培训、继续教育等计划的实施，有计划地安排本科人员积极参与学术交流或专题研讨会。 7、安排外来进修、实习生到各个专业组学习，定期检查进修或实习计划、毕业论文的完成情况。
中国国际广播电台复试笔试经验 上午8点45到了八宝山地铁站旁的国际台大楼，9点开考，考场是3f的会议室。参加人数没细数，大概30-40人。XX 年.15的第一次笔试，我根据那个excel表名单统计了一下，有953人。不知道实际淘汰率是不是有这么恐怖。也不知道这一轮能有多少人进面试?或者说根本就没有面试/今年根本就不准备招人? 拿到试卷发现只有三道大题，大跌眼镜： 1.结合你的实际经历，谈一谈国际传播工作者需要怎样的能力和素质。 2.论述中美关系或者中日关系为什么错综复杂。 3.结合你的专业，谈一谈国际台如何改善工作。 其中第1和第3题如果本人没记错的话，一笔的时候就考过了。。。 总之尽人事，听天命。找工作到这个阶段的兄弟姐妹们，应该已经身经百战，心理素质都是杠杠的了，不介意一城一池之得失。 2020-05-14 上午8点45到了八宝山地铁站旁的国际台大楼，9点开考，考场是3f的会议室。参加人数没细数，大概30-40人。XX
年.15的第一次笔试，我根据那个excel表名单统计了一下，有953人。不知道实际淘汰率是不是有这么恐怖。也不知道这一轮能有多少人进面试?或者说根本就没有面试/今年根本就不准备招人? 拿到试卷发现只有三道大题，大跌眼镜： 1.结合你的实际经历，谈一谈国际传播工作者需要怎样的能力和素质。 2.论述中美关系或者中日关系为什么错综复杂。 3.结合你的专业，谈一谈国际台如何改善工作。 其中第1和第3题如果本人没记错的话，一笔的时候就考过了。。。 总之尽人事，听天命。找工作到这个阶段的兄弟姐妹们，应该已经身经百战，心理素质都是杠杠的了，不介意一城一池之得失。 2020-05-14 上午8点45到了八宝山地铁站旁的国际台大楼，9点开考，考场是3f的会议室。参加人数没细数，大概30-40人。XX 年.15的第一次笔试，我根据那个excel表名单统计了一下，有953人。不知道实际淘汰率是不是有这么恐怖。也不知道这一轮能有多少人进面试?或者说根本就没有面试/今年根本就不准备招人?
人员职责 检验科主任职责 1、在院长的领导或指导下，实行科主任负责制，负责本科的检验、教学、科研和行政管理工作。 2、制定本科工作计划，组织实施，经常督促检查，按期汇报总结。 3、督促本科人员认真执行各项规章制度、检验操作规程、质量管理和消毒隔离工作。 4、参加部分检验工作，并检查科内人员的检验质量。 5、督促科内人员正确使用与保管毒株、剧毒、易燃、易爆等药品及器材、审签药品器材与报销，经常检查安全措施，严防差错事故。 6、负责本科人员的业务训练、技术考核以及进修实习人员的培训及教学。 7、确定本科人员分工、调班（临时调度）、值班和外出学习、进修、服务等工作。 8、制定本科的科研计划、组织实施，总结经验，学习使用国内外新成果，不断改进检验技术水平。 9、督促本科人员做好登记统计工作，负责考勤、考核，提出升、奖、调、惩等意见，做好经济核算、奖金分配工作。 10、经常与临床科室联系，征求意见，改进工作。 11、副主任协助主任负责相应的工作。
正（副）主任技师职责 1、在科主任领导下，指导全科的检验、教育、科研、技术培训与理论提高工作。 2、经常检查检验质量，担任特殊检验技术工作，解决业务上的复杂疑难问题。 3、指导科内各级检验人员，做好检验工作，有计划地开展基本功训练。 4、经常深入临床科室征询对检验工作的意见、介绍新的检验项目和临床意义；必要时参加临床科室的疑难病例讨论或查房，主动配合临床医疗工作。 5、担任教学及进修、实习人员的培训工作，负责本科人员的业务学习和技术考核，不断提高业务技术水平。 6、运用国内外先进经验，吸收最新科研成就，不断改进检验工作，开展新的检验项目。 7、督促下级检验人员认真贯彻执行各项规章制度和检验操作规程。 8、指导全科结合临床医疗，开展科学研究工作。
主流国际短波电台普通话广播B09版频率表 (2009年10月25日——2010年3月27日) 本频率表中所标注之默认时间均为时间，默认频率单位皆为千赫兹，所列国际电台以英文字母缩写或全称排序。 免责声明：本频率表仅作电台频率数据客观记录及收听学习之用，不得用于非法用途。由于短波国际广播具有明显的政治倾向性，请收听者注意容甄别！ ABC-RA 澳洲广播电台 2100-2230 9475，11660，11760，11825 AIR 印度德里广播电台 1945-2115 11840，15795，17705 BBC World Service 0600-0700 6020，6095，6170，7325，7415，9465 0700-0730 6020，6170，9465 2100-2330 6095，7535，9605，11895 CBS-RTI （A09） 0600-0700 6105，6150，11635（东南亚），11710，11885 0700-0800 6105，6150，7270，9660，9685，11635（东南亚），11710，11885 0800-0900 860（东北美），9660 0900-1000 860（东北美），9660 1000-1100 9660 1100-1200 6915（东北美） 1200-1300 1210（北美），5950（西北美），11640，11885，15245 1300-1400 1210（北美），11640，11885，15245，15290（东南亚） 1400-1500 1210（北美） 1800-1900 603，1008，1422，1503，6085，6150，7385，9780，11665 1900-2000 603，1008，1503，6085，6150，7385，9680，9780，11665，11710 2000-2100 603，1008，6150，7385，9680，11665，11710 2100-2130 603，1008，1098，1503，6085，6150，7385，7445（东南亚），9680，9780，11665，15265（东南亚） 2130-2200 603，1008，1098，6085，6150，7385，7445（东南亚），9680，9780，11665，15265（东南亚） 2200-2300 603，1008，1098，6075，6145，6085，7270，7385，9680，7445（东南亚），11665 2300-0000 603，1008，1098，6075，6145，7365，7385，9680，11665 0000-0100 603，1008，6075，6145，7365，7385，9680，11665
检验科工作人员岗位职责 （一）检验科主任岗位职责 1、在院长的领导下，负责本科的业务工作和行政管理等工作，定期安排科室内政治学习。 2、督促本科各级人员认真执行卫生部“医务人员医德医风手册”，坚持以病人为中心，做好优质服务工作。 3、制订本科工作计划并组织实施，经常督促检查，按期总结汇报。检查科内人员的检验质量，督促质量控制工作的落实。负责本科人员的业务学习，技术考核，提出升、调、奖、惩意见。做好进修、实习人员的培训安排及临床教学工作。 4、负责科室内工作人员继续教育培训工作。 5、经常与临床科室联系，征求意见，改进工作。 副主任参照主任岗位职责执行，协助主任负责相应的工作。
（二）主任（副主任）检验师岗位职责 l、在科主任的领导下，组织、指导本专业的检验、教学、科研等工作，主动承担教学任务，参加科室班组的各项值班工作，完成医院、科室组织的各项目标考核和业务考核任务。 2、坚持以病人为中心，做好优质服务工作。 3、了解检验医学学科在国内外同行中的发展动向，制定本学科、专业发展规划，培养年青技术骨干，注重专业梯队建设。 4、负责指导本科室的检验医学工作，参与制定科室各专业的操作规程，督促检查检验人员在检测工作中执行操作规程，杜绝差错事故的发生。 5、做好质量控制监督工作，解决业务技术上复杂疑难问题；指导下级检验人员完成检验工作。 6、组织并指导科研、新技术开展工作，引进国内外先进实验技术，改进和引进先进的实验技术和方法，提高检验质量和本专业的学科水平。
7、指导科内人员的业务学习及基本技能训练，负责本学科的专题讲座，主持科内人员的业务考核及参加医院或科室组织的各专业技能或理论知识的考核。 8、经常与临床科室联系，征求意见，做好登记工作；指导进修、实习生的教学和检验技术操作。 （三）主管检验师岗位职责 l、服从科主任、班组长的领导和工作安排，接受上级检验师的业务指导，爱岗敬业，负责所在专业的检验、教学和科研工作，积极参加科室、班组的各项工作，完成医院、科室、班组下达的各项目标考核和业务考核任务。 2、坚持以病人为中心，做好优质服务工作。 3、做好质量控制工作，能正确解决业务技术上较复杂疑难问题。 4、提高专业技术水平，开展科研、教学工作，做好下级检验人员技术培训和进修、实习人员的指导
2011年1月18日,对于我国的国际传播事业而言,无疑是一个值得记忆的节点。这一天,由中国国际广播电台创办的中国国际广播电视网络台(CIBN)在北京宣告成立。这标志着一家拥有61个传播语种、全业务媒体形态和浓厚国际化特色的新媒体国际传播平台的建设全面启动。日前,记者来到北京石景山路甲16号院,走进中国国际广播电台台长王庚年的办公室,倾听这位从事传媒工作已超过30年的资深媒体人关于CIBN的一系列思考。 “受众不再是信息的被动接受者” 记者:什么是CIBN?CIBN作为一个新媒体国际传播平台将带给用户怎样的体验? 王庚年:CIBN的中文全称是中国国际广播电视网络台,它是国家广电总局批准成立的新媒体领域的国家广播电视播出机构。CIBN是在互联网和移动通信技术日益发展的条件下,以多语种、多类型、多终端的形态面向全球受众传播的新媒体国际传播平台,涵盖了网络视听节目、手机广播电视、互联网电视、IP电视、多媒体移动广播等各种新媒体业态。 CIBN作为新媒体国际传播平台,将带给用户全新的视听享受。首先是综合化。受众可以通过互联网和手机读报纸、看电视,也可以通过电视听广播、浏览网络,充分享受各种便捷服务和跨媒体传播体验。其次是交互化。受众不再是传统传播方式下信息的被动接受者,而将充分体验到从“接受者”向“参与者”的转变,从听广播、看电视向用电视、用网络转变。另外就是国际化。CIBN努力实现全球采集、全球发布、全球互动,面向全世界的用户提供海量信息服务,搭建中国与世界沟通的有效平台。 记者:CIBN较其他媒体拥有哪些优势? 王庚年:CIBN依托国际台这个专门从事国际传播的国家级媒体,与其他媒体相比,拥有独特的传播优势。
检验科人员竞聘演讲稿 检验科人员竞聘演讲稿 一有较强的敬业精神。 检验科室所服务的人群是各种各样的门诊病人、健康查体人员以及住院病人。每天做的项目很多，工作比较忙碌，繁琐，检验结果 的准确性是保证病人后续接受及时、有效治疗的基础，这需要有一 股敬业精神。十几年来，自己不断加强思想道德和业务技能的学习，提高工作的责任心，对待各项工作一丝不苟，认真负责，恪守救死 扶伤，全心全意为病患着想的宗旨，急病人之所急，尽心尽力为病 人服务，做好检验工作的每一项工作，站好每一天岗，及时完成院 领导和临床大夫交给的各项任务。 二有较丰富的工作经验 在检验科工作的十多年中，我先后做过常规检验，生化检验，免疫检验,血库等工作，在工作中注意积累和总结，虚心向同事，领导 请教，熟练操作技能，注重理论和实践相结合，对检验过程中出现 的各种异常及突发情况具有一定的处理能力。我相信，十多年检验 实践工作经验的积累，对于我今后站在更高的位置上全面考虑问题，是一笔宝贵的人生财富。 三有较强的组织协调能力 十几年来，在工作岗位上，尽量满足病人和临床大夫的各种合理要求，多年来，检验科室与医院各科室都建立了非常密切的合作关系，在科内团结同事，密切合作，向主任献计献策，共同把工作搞好。在工作中与其他科室积极配合，做到有求必应，热情帮助，受 到了病人和临床大夫的一致好评。
这所有的一切，都为我能够有信心站在检验科室主任竞聘的讲台上，向各位院领导、各位同事展示自我的信心源泉。接下来，如果我有幸能够竞聘成功，我将做好如下几个方面的工作： 一、按照检验质量标准，制定工作计划，并组织实施具体工作，认真履检验科职责和义务。检验科将继续坚持“以病人为中心，以质量为核心，为患者提供优质、便捷、高效、文明服务”的服务理念，不断加强医患沟通，定期征求各科意见，及时采取整改措施扬长避短，更好地位病人提供优质亲情服务。 三、培养经营意识，善于进行成本效益核算。 创造科室效益的同时节约不必要的开支，降低医疗成本，保障科室走持续发展的道路。 最后，请允许我在此郑重表态： 本次竞聘将成为我在医院不断提升自我，将工作精益求精的一个新台阶。无论竞聘成功与否，我都将一如既往地努力工作，虚心向在座各位领导和同事学习，保持乐观向上的心态，服从安排，为卫生事业的发展贡献自己的一份力量。 谢谢大家 各位领导： 大家好！感谢给我这次竞聘述职的机会。 我叫xx-x，，现年36岁，本科学历，学士学位，在职研究生在读。主管检验师，在检验科工作已有14年了，曾被评为市优秀团员和院内先进工作者。本着年轻上进，追求进步，想为社会，为医院多做点贡献的原则，参加这次竞聘。现在这里对我这些年来工作情况，向各级领导做一汇报。 一有较强的敬业精神。 检验工作服务的是各种各样的门诊病人，健康查体人员，住院病人。每天做上百种检验项目，工作比较忙碌，繁琐，需要有一股敬
全国各地电台频率大全 北京 城市频率电台 北京87.6 北京人民广播电台文艺台 北京88.2 中国国际广播电台EasyFM 北京88.7 中国国际广播电台 北京90.0 中央人民广播电台第三套节目文艺调频北京91.5 中国国际广播电台EasyFM 北京96.6 中央人民广播电台第二套节目经济频道北京97.4 北京人民广播电台音乐台 北京99.6 中央人民广播电台第二套节目 北京101.8 中央人民广播电台第四套节目民族广播北京103.9 北京人民广播电台交通台 北京106.1 中央人民广播电台第一套节目综合频道 福建 城市频率电台时间 福州89.3 福州广播二台 福州90.6 海峡之声广播电台 福州92.6 中央人民广播电台音乐台( 福州转播) 福州94.0 福州广播二台 福州94.4 福州广播二台 福州96.1 福建经济广播电台 福州97.6 福建人民广播电台交通音乐台 福州98.7 福建人民广播电台交通音乐台 福州99.6 海峡之声广播电台 福州103.6 福建人民广播电台交通音乐台 福州105.6 福州静安区调频广播电台 福州107.1 中国华谊广播公司 龙岩96.5 福建人民广播电台 龙岩104.8 福建人民广播电台经济台 南平88.0 福建人民广播电台 南平89.5 福建人民广播电台经济台 南平93.9 福建人民广播电台 南平100.9 南平人民广播电台 南平105.1 福建人民广播电台经济台 南平107.0 南平人民广播电台 宁德89.4 福建人民广播电台 宁德96.7 福建人民广播电台 宁德105.4 福建人民广播电台经济台 宁德107.3 福建人民广播电台经济台 莆田89.5 福建人民广播电台 莆田104.9 福建人民广播电台经济台
显色指数CRI 物体用该光源照明和用标准光源（一般以太阳光做标准光源）照明时，其颜色符合程度的量度，也就是颜色逼真的程度。以Ra表示，最大为100。作为衡量灯具品质的重要指数，显色指数关乎着灯具对物体本身色彩的还原度，显色越高，被照射物体的色彩就越真实。 显色分两种: 1、忠实显色，能正确表现物质本来的颜色需使用显色指数(Ra)高的光源，其数值接近100，显色性最好。2、效果显色，要鲜明地强调特定色彩，表现美的生活可以利用加色的方法来加强显色效果。采用低色温光源照射，能使红色更加鲜艳；采用中等色温光源照射，使蓝色具有清凉感；采用高色温光源照射，使物体有冷的感觉。 显色指数不是LED独有的，是所有的光源都有的一个参数，是对色彩的还原能力。日光的显色指数是100，白炽灯也是100，节能灯是80-90，LED是70-90。显色指数越低，肉眼看来颜色越失真。白炽灯的理论显色指数为100，但实际生活中的白炽灯种类繁多，应用也不同，所以其CRI值不是完全一致的。只能说是接近100，是显色性最好的灯具。 随着LED照明产品逐步取代传统照明，显色指数这个参数开始逐渐受到人们的关注。因此力汕电子推出了LPCE-2(LMS-9000A) 积分球&光谱仪测试系统和CHROMA-2手持式色度计，这两款设备均可以测试显色指数。CHROMA-2手持式色度计简单可携带，所以深受广大灯具厂家的亲睐。LPCE-2(LMS-9000A) 积分球&光谱仪测试系统可以测试各种LED灯具的CRI显色指数。 力汕电子推出的LPCE-2(LMS-9000A) 积分球&光谱仪测试系统和CHROMA-2手持式色度计已被广泛应用于品质部门和实验室，如Sharp Electronics in Memphis TN(USA), PT. SHARP SEMICONDUCTOR INDONESIA (Indonesia), TUV Rheinland InterCert Kft.( Hungary), Philips Lighting(Netherlands), Sony Semiconductor Corporation等。力汕之所以能赢得如此多的客户，是源于我们始终实践着正确的产品，正确的价格和正确的服务，未来力汕将始终以高质量的产品和优质的售后来服务广大客户，同时也欢迎各位新老客户的咨询。