text:
This invention presents a new "Hit-or-Jump" system and method for embedded testing of components of communication systems that can be modeled by communicating extended finite state machines. It constructs test sequences efficiently with a high fault coverage. It does not have state space explosion, as is often encountered in exhaustive search, and it quickly covers the system components under test without being "trapped", as is experienced by random walks. The algorithm has been implemented and applied to embedded testing of telephone services in an IN architecture, including the Basic Call Service (ECS) as well as other supplementary services.
1. A method of embedded testing of a component machine (A) in a system (C�A) comprising:
A) searching a current node in a local search graph in the system (C�A) until:
i. an edge transition is reached that is associated with unmarked transitions of the component machine (A);
a) including a path from the current node to the edge transition in a test sequence;
b) marking off an unmarked edge transition of the component machine (A) and moving to a new node;
c) erasing the local search graph
d) repeating the method in A) from the new node; or
ii. a search depth or space limit is reached without hitting any unmarked transitions of (A);
a) constructing a search tree, with at least one leaf node, and the current node as a root;
b) examining said at least one leaf node of the search tree, and selecting one of said at least one leaf node as a new leaf node;
c) including a path from the root to the leaf node, and moving to the new leaf node; and
d) repeating the method in A) from the new leaf node.
2. A method as in
3. A method as in
4. A method as in
5. A method as in
6. A method of embedded testing of a component machine in a system comprising:
a) searching a current node in a local search graph until (1) an edge transition is reached that is associated with unmarked transitions of a component machine, or (2) a depth or space limit is reached without hitting any unmarked transitions of the component machine; and
b) including a path from the current node to the edge transition, marking off the unmarked transitions moving to a new node and erasing a searched graph if an edge transition is reached, or otherwise constructing a leaf node search tree with the current node as a root, selecting a new leaf node and jumping to the new leaf node.
7. A method as in
8. A method as in
9. A method as in
10. A method as in
11. A method as in
12. A method as in
13. A method as in
This patent application claims priority from provisional application serial No. 60/138,398, filed Jun. 9, 1999, titled "Hit-Or-Jump: An Algorithm For Embedded Testing With Applications To IN Services" (David Lee, case 7; 22 pages, 4 sheets of drawings [informal])
1. Field of the Invention
The present invention relates to embedded testing of components in a system that can be modeled through extended finite state machines.
2. Description of the Prior Art
With the advanced computer technology and the increasing demand from the users for sophisticated services, communication protocol systems are becoming more complex, yet less reliable. Conformance testing, which ensures correct protocol implementations, has become indispensable for the development of reliable communication systems. Traditional testing methods tend to test these systems as a whole or alternately test their components in isolation. Testing these systems as a whole becomes difficult due to the formidable size of the systems. Furthermore, testing system components in isolation may not be always feasible due to the interactions among the individual system components. Typically, the tester does not have a direct access to the component under test; access is obtained through other components of the system. As a result, Embedded testing or testing in context has become one of the main focuses of conformance testing research in recent years. The goal of embedded testing is to test whether an implementation of a system component conforms to its specification in the context of other components. If control and observation are applied through one or more implementations that are above the protocol to be tested, the testing methods are called "embedded."
Different approaches for embedded testing are currently in use. These approaches are based on (1) fault models, (2) on reducing the problem to testing of components in isolation, (3) on test suite minimization, (4) on fault coverage, and (5) on the test of systems with semi-controllable and uncontrollable interfaces. Most of these approaches resort to reachability graphs to model the joint behaviors of all the system components. Unfortunately, the implementation of these approaches is plagued by state space explosion, as well as random walk errors.
The problem of random walk remains prevalent under current systems. For example, for a given system component, there is generally a need to test all the transitions or certain boundary values of system variables. Conventionally, a reachability graph is constructed, which is the Cartesian product of all the system components involved. Next, a test is derived that covers all the pre-specified parts of the component under test. Unfortunately, this exhaustive search technique is often impractical; it is impossible to construct a reachability graph for practical systems due to the state space explosion. To avoid this problem random walks have been proposed. At any moment, it is only necessary to keep track of the current states of all the components and determine the next step of test at random. This approach avoids the state space explosion but it may repeatedly test covered parts and take a long time to move on to the untested parts.
Furthermore, a random walk may become "trapped" at a certain part of the component under test or in a small neighborhood. Also, random walks have a low probability of crossing a "narrow bridge" to test the parts beyond the bridge, and may also miss unmarked transitions, even if they are nearby (more than one step from the current node). Finally, the great reliance on reachability graphs restricts space requirements in testing, and is dependent on the system under consideration.
The present invention, referred to as "Hit-or-Jump" provides a more efficient and accurate modeling environment through the use of communicating extended unit state machines (CEFSM). Specifically, a new method and system is disclosed for embedded testing of CEFSM's. The CEFSM model can also be easily adapted to other mathematical models such as Transition Systems, Labeled Transition Systems, and Petri Nets.
Specifically, the present invention tests pre-specified parts of a system component that is embedded in a complex communication system. The pre-specified parts are determined by practical needs or by system certification requirements. Thus, all the transitions or certain boundary values of system variables may be tested for a given system component. Under the "Hit-or-Jump" method and system, a local search is conducted from the current state in a neighborhood of the reachability graph. If an untested part is found (a "Hit"), that part is tested, and the process continues from that point. Otherwise, a subsequent random move is made to the frontier of the neighborhood searched ("Jump"), where the process then continues. This procedure avoids the construction of a complete system reachability graph. Furthermore, the space required is determined by the user, and it is independent of the systems under consideration. While a random walk may get "trapped" at certain part of the component under test, the disclosed method and system is designed to "jump" out of the trap and pursue the exploration further.
In a preferred embodiment, the Hit-or-Jump method is applied to the embedded testing of services on a telephone network. The examples given below typify the invention utilized in a system using the signaling data link (SDL) language. The telephone services associated with the invention appear in an Intelligent Network (IN) architecture with Basic Call Services (BCSs). In addition to BCS, five other services are included: Originating Call Screening (OCS), Terminating Call Screening (TCS), Call Forward Unconditional (CFU), Call Forward on Busy Line (CBL) and Automatic Call Back (ACB).
FIG. 1 illustrates the extended finite state machine (EFSM) intercommunication according to the present invention.
FIG. 2 illustrates a global architecture of the present invention
FIG. 3 illustrates the metrics of the service specification
FIG. 4 illustrates the metrics of the complete specification after a manual stop of the search/simulation.
FIG. 5 illustrates stop conditions of the blacklist process according to the present invention.
FIG. 6 illustrates stop conditions of the OCS module according to the present invention.
FIG. 7 illustrates the obtained test sequences of transitions during invocation of services according to the present invention.
FIG. 8 illustrates a series of transitions that allow the transition of the embedded module to be reached in the case of a stop output ready according to the present invention.
FIG. 9 illustrates the metrics of a module OCS according to the present invention.
FIG. 10 illustrates the metrics of a module CFU according to the present invention.
FIG. 11 illustrates a test sequence of "Hit-or-Jump" applied to the process responder of an INRES protocol according to the present invention.
FIG. 12 illustrates a second test sequence of "Hit-or-Jump" applied to the process responder of an INRES protocol according to the present invention.
FIG. 13 illustrates a flowchart describing the "Hit-or-Jump" method according to the present invention.
FIG. 1 illustrates the extended finite state machine (EFSM) intercommunication according to the present invention, where C is the environment EFSM, A is the specification EFSM under test, and B is the implementation of A. Machine C and A(B) communicate synchronously. A is represented in the context of C by the following notation: C�A. There is a need to test the conformance of B to A in the context of C where C and A are known, and B is a "black-box". It should be noted that C�A may not be minimized or strongly connected even if C and A are. Also they can be partially (incompletely) specified.
Under a preferred embodiment, deterministic EFSM's are used to model system components, which include the environment, the components under test and their implementation. It is understood that the technique can be adapted to other mathematical models, such as Transition Systems, Petri Nets and Labeled Transition Systems. Under the preferred embodiment, an EFSM is defined as a quintuple M:
M=(I,O,S,x{right arrow over ( )}, T)
where I,O,S,x{right arrow over ( )} and T are finite sets of input symbols, output symbols, states, variables, and transitions, respectively. Each transition t in the set T is a 6-tuple, defined as:
where st, qt, at, and ot are the start (current) state, end (next) state, input, and output, respectively. Pt(x{right arrow over ( )}) is a predicate on the current variable values and At(x{right arrow over ( )})defines an action on variable values.
Initially, the machine is in an initial state s(0) ε S with initial variable values: x{right arrow over ( )}(0). At some point, the machine attains state st, with the current variable values x{right arrow over ( )}. Upon input at, if x{right arrow over ( )} is valid for Pt, i.e., Pt(x{right arrow over ( )})=TRUE, then the machine follows the transition t, outputs ot, changes the current variable values by action x{right arrow over ( )}:=At(x{right arrow over ( )}), and moves to state qt.
For each state s ε S and input a ε I, all the transitions with start state s and input a can be configured to be ti=(s, qi, a, oi, Pi, Ai), with 1≦i≦r. In a deterministic EFSM, the set of valid variable values of these r predicates are mutually disjoint, i.e., XPi ∩ XPj=0, 1≦i ≠ j≦r. Otherwise, the machine becomes nondeterministic. In a deterministic EFSM, there is at most one transition to follow at any moment, since at any state and upon each input, the associated transitions have disjoint variable values for their predicates and, consequently, current variable values are valid for at most one predicate. Alternately, in a nondeterministic EFSM there may be more than one possible transition to follow.
There are two types of communications among the system components: (1) Synchronous communication by rendezvous without channels between; and (2) Asynchronous communication with channels between system components. Channels can be bounded or unbounded and both can be modeled by EFSM's. The interactions between the channels and system components are synchronous. Alternately, an additional variable can be used to "encode" different system components. Thus the whole environment can be modeled, including the channels to and from the system component under test, as one EFSM that communicates with the system component synchronously. It is understood that extended finite state machine have the same computing power as a Turing machine.
In general, it is not always possible to test for isomorphism of embedded components, even in the case of finite state machines (FSM's). Assuming that A and B are FSM's, machine isomorphism may be designated by A≅B. Furthermore, B≅A implies that C�B≅C�A. However, the converse is not true in general. For example, in FIG. 1, a and b are external inputs, 0 and 1 are external outputs, and x, y, t, u are internal input/outputs. As stated previously, C�B≅C�A. However, B≠A. Therefore, it becomes impossible to test A B in the context of C.
In practice, it is desired that B "behave correctly" in the context of C. That is, C�B≅C�A. Therefore, the problem is reduced to testing if C�B≅C�A. However the real goal is to test the component A, assuming that the environment machine C is correctly implemented. Suppose that A is tested in isolation. It would then be desirable to test all the transitions of A. That is, a testing sequence should be developed so that all the transitions of A are exercised. Similarly, in embedded testing, test sequences should be obtained (with external inputs) so that all the transitions of the component A are exercised. Specifically, tests are derived for C�A so that all the transitions of A are tested. Furthermore, different coverage of A may be desired that differs from the testing of all the transitions. As an example, the boundary values of the variables may be a test object. In such an instance, a test sequence for C�A is generally obtained for testing the component A in the context of C, so that the component machine A is covered according to a pre-specified criterion. It is assumed in this instance that C is correctly implemented; as such, the coverage of C would not be an issue.
It should be pointed out that in the above example, the systems may or may not have reset. EFSM's with reset transitions may be considered as a special case by inserting a reset edge from each state to the initial state, independent of the variable values. For the sake of brevity, only machines without reset will be considered in the disclosure.
A further consideration in the example is the existence of livelock and deadlock in the system. Livelock in C�A is a loop without external inputs, and it is reachable from the initial state. When the system C�A gets into a livelock, it will loop around indefinitely without any external inputs and may or may not produce external outputs. Under such circumstances, C�A can "move-on" by itself without any external control, and the external tester cannot drive the system C�A further to fulfill the testing task. This is undesirable system behavior in terms of embedded testing. Another undesirable system behavior is deadlock. During test generation, if a sink node is found (no outgoing transition) in C�A, the process is aborted, a "deadlock detected" is declared. In the system architecture, both livelock and deadlock are to be checked for system designs, during protocol validation and verification research. It is assumed in the below discussion that the system under consideration C�A is free of livelock and/or deadlock.
In using the "Hit-or-Jump" method and system, three related methods are factored during the execution of a "Hit-or-Jump". They include (1) a structured algorithm, (2) random walk, and (3) guided random walk. Generally, a goal of the invention is to cover all the transitions of the component machine under test. Furthermore, different tests may be generated to invoke different coverages—the modifications can be implemented simply through the use of different markings.
From the initial state, a test sequence is generated so that all the transitions of component machine A are covered at least once. The algorithm includes three steps: (1) assign a distinct color (transition) to each transition of A; (2) construct a reachability graph of C�A where each edge of C�A is marked with a color from A if it is derived from that transition of A; (3) from the initial node of C�A, find a path of minimal length such all the colors are covered at least once. By using this structure, the "Rural Postman" problem to this covering path problem can be reduced (i.e., the problem is NP-hard). There are various heuristic procedures for solving this problem.
However, these algorithms require the construction of the reachability graph of C�A. It is often impossible in practice to construct such implementations due to the state explosion. Consequently, unstructured algorithms such as random walks are considered, which do not require the construction of reachability graphs.
The process is started from the initial node (SC (0), SA (0), x{right arrow over ( )}(0)) where SC (0), SA (0), and x{right arrow over ( )}(0) are the initial state of C and A and initial variable values, respectively. Among all the possible outgoing edges in the reachability graph from the initial node, one edge is selected uniformly at random, and followed to the next node in the reachability graph. For example, if after k steps we arrive at a node (SC (k), SA (k), x{right arrow over ( )}(k)), then all the outgoing edges are examined from this node and one edge is selected (uniformly at random) to follow. Meanwhile, if there are colors associated with the chosen edges that have not been marked (exercised), they are marked off. The process is then repeated until all the colors are marked off. The items that are kept track of during the walk for the test sequence are limited to: (1) The current node (SC (k), SA (k), x{right arrow over ( )}(k)); (2) The colors that have not been marked off; and (3) The edges that have been walked through with the associated external I/0 sequence. There is no need to construct a whole reachability graph of C�A.
This procedure is the same as the random walk described above, with some exceptions. When a node is arrived at (SC (k), SA (k), x{right arrow over ( )}(k)), the outgoing edges are classified under the following: (1) with transitions of A involved, some of which are not marked; (2) With transitions of A involved and all of them are marked; and (3) Without any transitions of A involved. If the set (1) is not empty, we select one uniformly at random and follow that edge; otherwise if (2) is not empty, we select one uniformly at random and follow that edge; and, finally, if none of the above is true, (3) must be non-empty, and we select one uniformly at random and follow that edge. Guided random walks favor transitions of the embedded component under test, and among them give first priority to the transitions that have not been tested.
"Hit-or-Jump" Method and System
The "Hit-or-Jump" method and system avoids the aforementioned problems of random walk without the construction of a reachability graph. It further does not require a construction of a reachability graph of C�A either, and performs better than pure random walks. The functionality of "Hit-or-Jump" by itself is best seen through an examination of the initial condition, execution and termination of the algorithm performing the tasks:
The environment machine C is in an initial state SC (0), while the component machine under test A is in initial state SA (0), and the system variables have initial values x{right arrow over ( )}(0). It is understood that the initial states and variable values refer to the information known to he tested, and they are not necessarily the states and variable values after a system reset, which is often difficult to obtain in practice.
1. "Hit"
From the current node (SC (k), SA (k), x{right arrow over ( )}(k)) conduct a search (depth-first or breadth-first) in C�A until:
(a) An edge is reached that is associated with unmarked colors (transitions) of the component machine A, in accordance with a local search graph (a "Hit"). Then:
i. Include the path from the current node to the edge (inclusive) in the test sequence under construction;
ii. Mark off the newly exercised colors (transitions) of A;
iii. Arrive at a node (SC (k+1), SA (k+1), x{right arrow over ( )}(k+1));
iv. Erase the searched graph;
V. Repeat from 1. or
(b) Reaching a search depth or space limit without hitting any unmarked colors (transitions) of A. Then move to 2.
2. "Jump"
(a) Constructing a search tree, rooted (SC (k), SA (k), x{right arrow over ( )}(k)).
(b) Examine all the leaf nodes of the tree, and select one uniformly at random.
(c) Include the path from the root to the selected leaf node in the test sequence.
(d) Arrive at the selected leaf node (SC (k+1), SA (k+1), x{right arrow over ( )}(k+1))(a "Jump")
1. Repeat from 1.
The algorithm terminates when all the colors (transitions) of A have been marked off.
An embodiment of the invention can be further seen in FIG. 13. When the "Hit-or-Jump" testing is initiated 130, the current state is set equal to the initial state. A local search is conducted 131 from the current state VC, where a local search graph is obtained (FIG. 13, G), as well as a search tree (FIG. 13, T), which contains a number of leaf nodes. When the local search graph G is analyzed 132, the invention determines whether there are any unmarked transitions existing from a previous state Vp to a current state VC.
If an unmarked transition is found (a "Hit"), a path is included on the tree T from the current state VC to the found state VC′. At this point 133, the transition from the past state Vp to the current found state VC′is marked off, the local search graph G is erased, and the test moves to the found state. Once the test moves to the found state, the found state VC′, becomes the current state VC. The test then queries whether all the transitions are marked 134. If all the transitions are found to have been marked, then the test terminates 135. If a transition is found not to be marked, then the test repeats the process from 131, where a new local search graph G is obtained.
If test 132 determines that there are not any unmarked transitions existing from a previous state Vp to a current state VC, the test moves to 136 ("Jump") , where a leaf node VC′ of the search tree T 131 is chosen uniformly at random. A path is then included on tree T from the current node VC to the leaf node VC′ in the test sequence. The local search graph G is then erased, and the test moves to state VC′, and the state VC′ is set as the current node VC.
The above description describes an embodiment of the basic Hit-or-Jump method and system. There are further variations that may be implemented from the basic method disclosed above. Some of the variations and/or additions are described below.
One variation incorporates the principles of a guided "Hit-or-Jump". For the "Jump" described above, a leaf node of the locally searched graph (tree) is selected uniformly at random and the process proceeds from there. However, certain priorities can be enforced in selecting the leaf nodes, much like a Guided Random Walk (described above). For instance, the outgoing edges can be examined from each leaf node and classified with a priority: (A) with transitions of A involved, some of which are not marked; (B) with transitions of A involved and all of them are marked; and (C) Without any transitions of A involved. A "guided Jump" is then conducted according to the leaf node priorities (as in a Guided Random Walk).
Another variation can be made regarding space requirements. Often the environment machine C (and also A) is very large. It is thus impossible to construct a reachability graph of C, A, or C�A. The present invention does not need any of these graphs. As a result, for each "Hit" or "Jump" step, a local search graph is constructed on-line, where the local search graph is a subgraph of C�A. This can be accomplished by a Depth-first search, for instance. The size of the subgraph, hence the space requirement, is determined by the users, and is independent of the machines A and C. When constructing a search tree on-line, the internal transitions of C�A can be compressed to further save space.
A further variation may be made with regard to the fault models. A general procedure may be implemented that is independent of any fault models. Only component machine A is covered, and the procedure can also be used for test generation associated with fault models.
Yet another variation may be implemented concerning coverage. Under a preferred embodiment, all the transitions of A are covered. However, the algorithm can also be extended to: (1) Covering some (not necessarily all) transitions of A, which are specified by users or the testers; (2) Covering some states of A; and (3) Covering some transitions and states of A along with specified variable values such as boundary values. A distinct color can be assigned to each entity to be covered, and run "Hit-or-Jump" until all the colors are covered.
Yet another variation may be implemented concerning local testing. Local testing is a search conducted in a component machine with very restrictive assumptions (reducing to testing isolated machines). "Hit-or-Jump" conducts a local search within C�A without any assumption on A or C.
When the "Hit-or-Jump" method and system is implemented in another embodiment of the present invention, a software tool is developed that also drives an ObjectGEODE simulator. In this embodiment, the simulation is used in exhaustive mode for the implementation. In order to maximize the effectiveness of the embodiment, the advantages and limitations of the ObjectGEODE simulator were taken into account. The main features and limitations can be seen as follows:
1. A simulation in exhaustive mode can be stopped on a condition. A stop condition is a boolean expression. If during the simulation it becomes true, then the simulator stops. In this case two files can be obtained: one containing the partially deployed automaton and another one with the scenario (in a file whose extension name is .bl.scn). If the simulation is actually completed, these two files are available as well.
2. A stop condition may be a disjunction of other stop conditions (thus modeling a set of conditions). In case it becomes true in the middle of simulating, the verdict (the result) will not point out all the conditions in the disjunction that have become true.
3. A scenario is a series of signal inputs (a sequence) fired by the simulator from the initial state, aiming at achieving the exhaustive simulation of the specification. Each SDL state from which the input is accepted by the SDL process is given in the scenario.
4. A deployed automaton corresponds to the contents of the file associated to the simulator's variable "edgesAump" in an exhaustive mode. This automaton is logically an FSM, and contains hooks to the SDL specification (and to the scenarios), and the SDL values (local variables and signal arguments) have been instantiated, either partially (interrupted simulation) or fully (exhaustive running).
5. Each simulation in exhaustive mode produces a new deployed partial automaton; when an interrupted simulation is resumed a new partial automaton is produced, which generally has nothing to do with the previous one. Nevertheless the newly produced scenario includes the previous one: this property along the simulations will be the Ariadne's clue.
6. It is possible to make the exhaustive simulation to be a depth-first search (DFS) or a breadth-first search (EFS) in the SDL specification, and to stop it on a depth limit value. In this last situation, a scenario is not obtained.
The aim is to get a unique sequence in the fully deployed automaton, corresponding to a path starting at the initial state that contains all the transitions of the embedded component under test yet without constructing the fully deployed automaton. The tool needs the following command-line options to interface the method and system:
sdl SPEC.pr: This input file is the protocol specification in SDL textual syntax. It must not be empty.
stop SPEC.stop: This input file contains a disjunctive stop condition, modeling the set of the embedded system component transitions. It defines the embedded system and hence must not be empty.
depth-lim 1: The given positive integer 1 is a depth limit that will be passed to the simulator; we stop when a search (DFS or BFS) reaches a depth of 1.
feed SPEC.feed: This input file only contains the inputs that the simulator can fire from the environment in order to stimulate the whole system. Hence no input of the embedded component appears in this file. It may be empty only if SPEC.scn is not (see below).
init SPEC.init: This input file only contains protocol-dependent variable initializations for the simulator ("let" clauses). It may be empty.
scn SPEC.scn: This input file contains an initial scenario only made of to-be-fired transitions for the embedded systems (in order to directly stimulate them, since they have no connection with the environment and hence have no associated feed clauses). It may be empty only if SPEC.feed is not (see above).
seq SPEC.seq: This output file contains a test sequence for the embedded system component. The sequence is a series of pairs of inputs and outputs.
The first step of the tool is to configure and produce three start-up files that will be used to drive the simulator:
1. main.startup: loads SPEC.feed, the initial conditions (SPEC.init), the current scenario, and specifies the exhaustive and DFS mode, together with the depth limit value (1).
2. stopsearch.startup: this file is devoted to the identification of the stop condition in the disjunction (initially in SPEC.stop) that actually interrupted the simulation, and thus works-around the aforementioned "stop condition" limitation of ObjectGEODE mentioned previously (item 2).
3. final.startup: It loads SPEC.feed and replays the final scenario obtained after hitting all the colors (transitions) of the embedded system component in order to make ObjectGEODE output a SPECJog file, from which the test sequence is extracted(into SPEC.seq).
The simulation is started with the main.startup file. There are two possible situations:
(1) The simulator outputs a SPEC.bl.scn file. This file is output if and only if an uncovered transition of the embedded system is "Hit" (see stop condition feature of ObjectGEODE above, item 1)). The simulator is then run again with the stop_search.startup file in order to identify the stop condition that corresponds to the Hit transition among the current disjunction (i.e., the set of uncovered transitions). This start-up drives a dichotomous search in the following way: Let E be the set of the candidate stop conditions.
There are only two possible cases:
1) E is a singleton.
Then there is no ambiguity in this case. The "Hit-or-Jump" process has successfully completed. The simulator is then run with the final.startup file (see above) and extract from the SPEC.Iog the test sequence.
2) E has at least two elements.
In this case, E is divided into two non empty sets E1 and E2 with approximately the same cardinality. One step is "undone" in the current scenario and a simulation is subsequently started with E1 in BFS mode with a depth limit of two. The simulator is configured to build all the transitions starting at the previous state where it stopped. Only two cases can occur:
i. The simulator stops at depth 1
This means that the transition of the component is "Hit" again under test because it did not try to build the deployed automaton until depth two (and it was not known that the sought-after transition was at depth one). Thus the transition to be Hit belongs to the subset E1. The search is then resumed with E1 instead of E.
ii. The simulator stops at depth 2
This means that the deployed automaton is built at depth two—therefore the transition to be Hit is not encountered (it was known that the transition was at depth one). Therefore, the sought-after transition does not belong to E1. The search is resumed with E2 instead of E.
Note: The cost of this dichotomous search is logarithmic in the number of stop conditions in the disjunction.
(2) The simulator does not output a SPEC.bl.scn file. This means that the simulator stopped after reaching the depth limit 1. In other words, the simulator did not find any transition that satisfies one of the stop conditions in the disjunction. Thus a "Jump" is to be made.
However, a file may be generated that contains the partially deployed automaton as a result of the interrupted simulation, wherein the current state in the EFSM (SDL specification) and/or the path from the initial state is not known (see features and limitations of ObjectGEODE above, items 3, 4 and 6). In such a case the deployed automaton is parsed and a DFS is conducted on it. A leaf node is then chosen uniformly at random and a path (preferably the shortest) is found for the current state to the selected leaf node. The path is then appended at the end of the constructed scenario, and the simulation is resumed.
A further embodiment exists of the "Hit-or-Jump" method and system is disclosed as occurring on a network system, shown in FIG. 2, where the invention is applied to Intelligent Network (IN) telephone services. All of the features in the system (FIG. 2) are serially and communicatively coupled in the system. The Network block 200 is composed of two blocks: the Basic Call Service (BCS) 201, and a Features Block (FB) 202 that represents those services. The BCS block contains three processes that are typically implementing software: the Call Manager 207, the Call Handler 206 and the Feature Handler 205. The Call Manager 207 is responsible for the management of a call and controls the Call Handler 206 and the Feature Handler 205. The Call Handler 206 takes charge of a call, while the Feature Handler 205 provides access to the services while being connected to the Feature Manager 212, located in the Feature block 202.
The Feature block 202 is composed of five processes that represent the services: the Call Forward Unconditional (CFU) 208, the Call Forward on Busy Line (CFB) 209, the Automatic Call Back (ACB) 210, the Originate Call Screening (OCS) 211, and the Feature Manager 212. The Feature Manager 212 controls the remaining features 208-211 in the Feature Block 202 and further establishes a link between the Feature Handler 205 and the services. A Black List can be instantiated twice in order to obtain a black list on calls start, OCS services, and a black list at calls arrival (Terminal Call Screening (TCS), not shown).
As stated previously, the service integrates supplementary services including OCS 211 (see also FIG. 9), Terminal Call Screening (TCS), CFU 208 (see also FIG. 10), CFB 209 and ACB 210. The system has been described using the SDL language regarding call treatment, service invocation and user management. The system is located at the Global Functional Plane (GFP), while taking some concepts of the Distributed Functional Plane (DFP). It consists of different functional entities that are represented by the Network block.
The model can be configured to allow the execution of different calls in parallel, as well as calls initiated by the network. The environment (i.e., the users), are also modeled as SDL process instances that comprise the Users Block 204. The user process represents a combination of a phone line, a terminal and a user. It is relatively complete with respect to the service-usage life-cycle, with user-activations, deactivations, updates and invocations all modeled therein.
In order to provide a general idea of the complexity of the SDL system specifications, FIG. 2 illustrates the global architecture of the system, while in FIG. 3 discloses some relevant metrics. The global system can be simulated using exhaustive simulation in a mode that obtains the complete reachability graph. FIG. 4 illustrates some information concerning the numbers of states, transitions, etc, obtained after a manual stop of the exhaustive search/simulation. The reachability graph is not constructed herein due to the formidable state space requirement of the system.
The invention disclosed in this embodiment is executed on the OCS service module, which is a system component that is embedded in the Features Block and does not possesses any link with the environment. For the embedded testing of this module, each of the branches should be traversed at least once. Stop conditions are used to represent the characteristics of each branch. To distinguish each branch of the component, the stop conditions are hand-crafted. FIG. 5 illustrates the stop conditions of OCS module.
In order to perform the simulation of the system, a startup is configured that plays the role of the environment. It starts each process by firing the first transition. Next, some variables and services are initialized. These include services and actions capable of being invoked by subscribers (e.g., hangups, activations, disactivations, normal dialing). In this embodiment, the variables are set at approximately 80 actions for each user. The results are shown in FIG. 6. It should be noted that, in the worst case, when finding the stop condition input add_list_elmnt to blacklist and output msg_info from blacklist (FIG. 6, stop #6), the simulator will have only passed through 103 transitions. When this is compared to the metrics of the complete specification after a manual stop of the search/simulation (FIG. 4) it becomes evident that the "Hit-or-Jump" algorithm effectively finds untested transitions without constructing the reachability graph. Furthermore, the total test sequence is short; the time corresponds to the CPU real-user time (Sun Sparc Ultra-1).
Once all the transitions of the embedded component OCS module have been traversed, a single test sequence is obtained, which corresponds to the total path that has been traversed from the environment to the last transition of the module. The obtained sequence of transitions in this embodiment is 150; in other words, only 150 transitions need to be taken to cover the whole OCS module in the context. The segment of the sequence in FIG. 7 exhibits the invocation of services, while FIG. 8 shows a series of transitions that allow the transition of the embedded module to be reached in the case of the stop output ready (see FIG. 6, stop #3). The complete test sequence of 150 transitions that cover the whole embedded OCS service module is in the Appendix. An identical test performed under a Random Walk (see above) generates a test sequence of 1402 transitions. When the two methods are compared, it is clear that "Hit-or-Jump" produces a test sequence with a same fault coverage as a Random Walk but is an order of magnitude shorter.
The "Hit-or-Jump" method and system can additionally be performed on the embedded testing of the service CFU. Moreover, the "Hit-or-Jump" method and system can also be applied to the process Responder of the INRES protocol (see FIG. 11 and 12). Various test sequence lengths have been obtained with different mode of search, BFS (Breath-first-search), DFS (Depth-first-search), Merge (a DFS and then a BFS), and a Random Walk.
Although exemplary embodiments of the invention have been described in detail above, it is understood that many additional modifications are possible in the exemplary embodiments without departing from the spirit and scope of the invention. For example, the method and system can be adapted to other mathematical models such as transition systems and labeled transition systems, and can also be adapted to embedded testing of systems specified by other languages such as LOTOS and ESTELLE. The system can also be implemented to conduct Internet Protocol testing.
Other variations or generalizations can also be implemented. For instance, if there has been no Hit for a large number of Jumps, one might "backtrack" to the previous Hit, and Jump to a different node to proceed with testing. Furthermore, various depth values may be used; a larger depth value increases the probability of hitting an uncovered part of the component under test. However, it may require more space and time for each step. A long "Jump" implies a longer subsequence in the test for this step. These modifications would it depend on the system under test to choose a good depth value. As indicated earlier, one can always choose a depth value that is within the limit of affordable memory space.
A complete test sequence of 150 transitions that cover the whole embedded OCS service module in an Intelligent Network appear as follows:
des (0, 150,151)
(0, "NULL/started_acb", 1)
(1, "NULL/started_cfb",2)
(2, "NULL/started_cfu", 3)
(3, "NULL/started_b1",4)
(4, "NULL/started_b1", 5)
(5, "started_acb/NULL",6)
(6, "started_cfb/NULL",7)
(7, "started_cfu/NULL",8)
(8, "started_b1/NULL",9)
(9, "started_b1/user started",10)
(10, "NULL/user_started",11)
(11, "NULL/user_started", 12)
(12, "NULL/user_started", 13)
(13, "NULL/user_started", 14)
(14, "user_started/user_started_ack", 15)
(15, "user_started/user_started_ack",16)
(16, "user_started/user_started_ack", 17)
(17, "user_started/user_started_ack", 18)
(18, "user_started/user_started_ack", 19)
(19, "user_started_ack/NULL", 20)
(20, "user_started_ack/NULL", 21)
(21, "user_started_ack/NULL", 22)
(22, "user_started_ack/NULL", 23)
(23, "user_started_ack/schedule_user_[true],", 24)
(24, "schedule_user[true]/offhook", 25)
(25, "offhook/dial_tone",26)
(26, "dial_tone/feature_op[ocs,updat]", 27)
(27, "feature_op [ocs, updat]/user_trigger[ocs , updat, 1, 1]", 28)
(28, "user_trigger[ocs,updat, 1,1]/update[ocs,1,user(1)]", 29)
(29, "update[ocs,1,user(1)]/update[ocs,1,user(1)", 30)
(30, "update [ocs, 1 ,user (1)]/ready", 31)
(31, "ready/add_list_elmnt[1]", 32)
(32, "add_list_elmnt [1]/feature_op_ok", 33)
(33, "feature_op_ok/onhook", 34)
(34, "onhook/cut_connection",35)
(35, "cut_connection/cut_connect [ocs]", 36)
(36, "cut_connect[ocs]/cut_connection", 37)
(37, "cut_connection/cut_connect_ack", 38)
(38, "cut_connect_ack/cut_ack",39)
(39, "cut_ack/cut_connect_ack", 40)
(40, "cut_connect_ack/net_trigger[o_end_call 1, 1,1]", 41)
(41, "net_trigger[o_end_call, 1,1]/resume_call"o_end_call, disconnecting, "1, 1]", 42)
(42, "resume_call [o_end_call, disconnecting, 1, 1]/end_leg[1, 1]", 43)
(43, "end_leg[1, 1]/line_free",44)
(44, "line_free/user_ack", 45)
(45, "user_ack/cm_ack",46)
(46, "cm_ack/handler exit[call_handler(1)]", 47)
(47, "handler_exit[call_handler(1)]/schedule_user [true]", 48)
(48, "schedule_user [true]/offhook",49)
(49, "offhook/dial tone", 50)
(50, "dial_tone/dialled [2]", 51)
(51, "dialled[2]/net_trigger[addressed, 1,2]", 52)
(52, "net_trigger[addressed,1,2]/invoke[ocs,1, 2,user(1) ,addressed]", 53)
(53, "invoke[ocs,1,2,user(1) ,addressed]/invoke[ocs, 1, 2 user(1), addressed]", 54)
(54, "invoke[ocs,1,2,user(1), addressed]/continue",55)
(55, "continue/continue", 56)
(56, "continue/resume_call [addressed, connecting, 1,2]", 57)
(57, "resume_call [addressed, connecting, 1 , 2]/net_trigger [analysed, 1,2]", 58)
(58, "net trigger[analysed,1,2]/invoke[cfu,1,2,user(1) , analysed]", 59)
(59, "invoke[cfu,1,2,user(1) , analysed]/invoke[cfu,1,2,user(1),analysed]", 60)
(60, "invoke[cfu,1,2,user(1),analysed]/proceed[3]", 61)
(61, "proceed[3]/proceed [3]", 62)
(62, "proceed[3]/resume_pall [analysed,completing, 1,3]", 63)
(63, "resume_call [analysed, completing, 1,3) /phonestat_req [1,3]", 64)
(64, "phonestat_req[1,3]/called_isfree[user(3)]", 65)
(65, "called_isfree [user (3)]/ringback_tone", 66)
(66, "ringback_tone/user_ack",67)
(67, "user_ack/ring_start", 68)
(68, "ring_start/user_ack", 69)
(69, "user_ack/net_trigger[completion, 1,3]", 70)
(70, "net_trigger[completion, 1,3]/resume_call [completion, ringing, 1,3]", 71)
(71, "resume call[completion, ringing, 1 ,3]/action[false]", 72)
(72, "action[false]/user_ack", 73)
(73, "user_ack/action[false]", 74)
(74, "action [false]/offhook", 75)
(75, "offhook/call_completed", 76)
(76, "call_completed/conv_caller", 77)
(77, "conv_caller/call_completed", 78)
(78, "call_completed/conv_called", 79)
(79, "conv_called/net_trigger [acceptance, 1 , 3]", 80)
(80, "net_trigger[acceptance, 1,3]/resume_call[acceptance,call_in_progress,1,3]", 81)
(81, "resume_call [acceptance, call_in_progress ,1,3]/call_suitch", 82)
(82, "call_switch/schedule_user [true]", 83)
(83, "schedule_user [true) /offhook", 84)
(84, "offhook/dial_tone", 85)
(85, "dial_tone/dialled[1]", 86)
(86, "dialled[1]/net_trigger[addressed,5,1]", 87)
(87, "net_trigger[addressed,5,1]/resume_call[addressed, connecting,5,1]", 88)
(88, "resume_call [addressed,connecting, 5, 1]/net_trigger[analysed, 5, 1]", 89)
(89, "net_trigger [analysed, 5, 1]/resume_call (analysed, completing, 5, 1]", 90)
(90, "resume_call[analysed ,completing,5,1]/phonestat_req[5,1]", 91)
(91, "phonestat_req[5 ,1)/called_isbusy[user(1)]", 92)
(92, "called_isbusy[user (1)]/net_trigger[occupation,5,1]", 93)
(93, "net_trigger[occupation,5,1]/resume_call[occupation,disconnecting, 5,1]",94)
(94, "resume_call[occupation, disconnecting,5, 1)/busy_tone", 95)
(95, "busy_tone/onhook",96)
(96, "onhook/net_trigger[o_end_call,5, 1]", 97)
(97, "net_trigger[o end_call,5,1]/resume_call[o_end_call,disconnecting,5, 1]", 98)
(98, "resume_call[o_end_call, disconnecting, 5,1]/end_leg[5,1]", 99)
(99, "end_leg [5,1]/line_free", 100)
(100, "line_free/user_ack", 101)
(101, "user_ack/cm_ack", 102)
(102, "cm_ack/handler_exit[call_handler (3)]", 103)
(103, "handler_exit [call_handler(3)]/schedule_ch", 104)
(104, "schedule_ch/action[true]", 105)
(105, "action [true]/onhook", 106)
(106, "onhook/net_trigger[t_end_call,1,3]", 107)
(107, "[net_trigger[t_end_call,1,3)/resume_call[t_end_call, disconnecting,1 ,3]", 108)
(108, "resume_call[t_end_call, disconnecting,1,3]/busy_tone", 109)
(109, "busy_tone/onhook", 110)
(110, "onhook/net_trigger[o_end call, 1, 3]", 111)
(111, "net_trigger[o_end_call,1,3]/resume_call[o_end_call, disconnecting,1,3]", 112)
(112, "resume_call [o_end_call ,disconnecting,1,3]/end_leg [1,1]", 113)
(113, "end_leg[1,1]/line_free", 114)
(114, "line_free/user_ack", 115)
(115, "user_ack/cm_ack", 116)
(116, "cm_ack/end_leg[3,1]", 117)
(117, "end_leg [3, 1]/line_free", 118)
(118, "line_free/user_ack", 119)
(119, "user_ack/cm ack",120)
(120, "cm_ack/handler_exit [call_handler(2)]", 121)
(121, "handler_exit[call_handler(2)]/schedule_user[true]", 122)
(122, "schedule_user[true]/offhook", 123)
(123, "offhook/dial_tone", 124)
(124, "dial_tone/dialled[3]", 125)
(125, "dialled [3]/net_trigger [addressed, 1 , 3]", 126)
(126, "net_trigger[addressed,1,3]/invoke[ocs,1,3,user(1) ,addressed]", 127)
(127, "invoke[ocs,1,3,user(1) ,addressed]/invoke[ocs,1,3,user(1) , addressed]", 128)
(128, "invoke[ocs,1,3,user(1) , addressed]/clear call", 129)
(129, "clear_call/clear_call", 130)
(130, "clear_call/resume_call[addressed, disconnecting, 1, 3]", 131)
(131, "resume_call[addressed, disconnecting,1,3]/busy_tone",132)
(132, "busy_tone/onhook", 133)
(133, "onhook/net_trigger[o_end_call, 1,3]", 134)
(134, "net_trigger[o_end_call, 1,3]/resume_call[o_end_call, disconnecting, 1,3]", 135)
(135, "resume_call[o_end_call, disconnecting, 1,3]/end _eg [1, 1]", 136)
(136, "end_leg[1, 1]/line_free", 137)
(137, "line_free/user_ack", 138)
(138, "user_ack/cm_ack", 139)
(139, "cm_ack/handler_exit [call_handler(4)]", 140)
(140, "handler_exit[call_handler(4)]/schedule_user[true]", 141)
(141, "schedule_user[true]/offhook", 142)
(142, "offhook/dial tone", 143)
(143, "dial_tone/feature_op[ocs,updat]", 144)
(144, "feature_op[ocs ,updat]/user_trigger[ocs, updat, 1, 1]", 145)
(145, "user trigger[ocs ,updat, 1,1]/update[ocs, 1 ,user(1)]", 146)
(146) "update[ocs, 1, user(1)]/update[ocs, 1, user(1)]", 147)
(147, "update[ocs, 1 ,user(1)]/ready", 148)
(148, "ready/add list_elmnt[1]", 149)
(149, "add_list_elmnt[1]) /msg_info[already_in_list)", 150)
Patent Citations
Non-Patent Citations
Referenced by
Legal Events
Original Image


text:
Vacuum Parts
Vacuum Cleaner Parts and Accessories: Find the Best For Your Cleaning System.
Cleaning homes is a task that most people dread. Busy schedules leave most of us with little or no time to clean homes on a daily basis. Vacuuming is a must at least once a week. Technology has revolutionized the types of vacuum cleaning systems being made available today, and they are now able to vacuum all the floors in your home and their parts and accessories also make it possible to dust and tidy furniture and other sections of your home. Again, the type of vacuum cleaning system and accessories you choose will depend on the pets and allergy prone members of your family. You might require parts such as HEPA filters to ensure that up to 99.97% of the allergens are kept at bay. Pollen and grass cutting seasons will require frequent vacuuming and probably require you to replace the parts of your vacuum cleaner including belts, bags, fans, switches, hoses and much more.
GoVacuum carries the largest selection of vacuum cleaning systems and accessories from all the major brands. You can shop and buy accessories to enhance the cleaning ability of your vacuum. Be it vacuum bags, vacuum filters, vacuum hoses, vacuum cleaner parts and other accessories, we stock a huge selection and even let you find the perfect accessory for you based on brand, price, etc. You can match the parts you need using our detailed parts diagrams. Save money and time by choosing to shop online for your vacuum cleaner parts and accessories. We offer free shipping and guaranteed low prices on all these parts and accessories so you can enjoy the best prices on vacuum accessories online.
Air-driven Turbo System Central Vacuum Accessory Package # 97801A$219.99The Model VM1200S Air-driven Turbo System Central Vacuum Accessory Package is a selection of popular basic central vacuum tools and accessories. 97801A Learn More
AirVac Deluxe Garage/Car Tool Kit LNVMGAR$115.82FEATURES HIGH-QUALITY HORSEHAIR BRUSH & BLACK FINISH30-FT CRUSHPROOF HOSE & RACKFLOOR/WALL TOOLDUSTING BRUSHCREVICE TOOLUPHOLSTERY TOOL WITH BRUSH2 FRICTION-FIT ABS PLASTIC WANDSON-BOARD TOOL CADDY;UPC : 727066092533Shipping Dimensions : 25.50in X 15.75in X 7.50inEstimated Shipping Weight : 18.1457 Learn More
AirVac New Air-driven Turbo System Central Vacuum Accessory Package # VM1200S +$219.85The Model VM1200S Air-driven Turbo System Central Vacuum Accessory Package is a selection of popular basic central vacuum tools and accessories. The carpet brush included with this kit is air-driven.The VM1200S kit includes: (1) V400S Central Vacuum Hose(1) VM179 12-inch Air-driven Turbo Brush(1) VMTE Metal Telescopic Central Vacuum Wand(1) VM166 Metal Hose Rack(1) VM253 Crevice Tool(1) VM256 Upholstery Tool with Brush(1) VM252 Floor/Wall Tool(1) VM254 Dusting Brush(1) VM258 On-board Tool Caddy(1) VMCD Deluxe Canvas Tool Caddy Learn More
Central Vacuum Hose - AirVac - V222$60.00Central Vacuum Hose - AirVac - V222 Learn More
AirVac VM101-8 Central Vacuum PVC Pipe - 8-Pack Of 8' Lengths$120.00AirVac VM101-8 Central Vacuum PVC Pipe - 8-Pack Of 8' Lengths Learn More
AirVac Deluxe Central Vacuum Hose, 30 Ft.$132.05AirVac Deluxe Central Vacuum Hose, 30 Ft. Learn More
Shark EP066, Dust Cup Filters , 3 pk.$14.95Dust Cup Filters (3pk) for EP066 Euro-Pro Learn More
Shark EuroPro XSB750 , EP750 Dust Cup Filters$18.74EuroPro XSB750 Replacement Dust Cup Filters for Handvac EP750 Learn More
SHARK MODEL SV735 DUST CUP WASHABLE FILTER 3PK$12.98SHARK MODEL SV735 DUST CUP WASHABLE FILTER PART NUMBER XSB735 Learn More
Euro Pro Shark XHF604H HEPA Filter$9.00This is a single genuine replacement Euro Pro Shark HEPA filter, part# XHF604H, for the Euro Pro Shark EP604 and EP604H Models. Learn More
Shark AC Adapter for Sweeper UV617 Part Number 1078FK$14.56Shark AC Adapter for Sweeper UV617 Part Number 1078FK Learn More
Euro-Pro Shark U610 Battery Pack 36000$45.00Euro-Pro Shark U610 Battery Pack 36000 Learn More
Shark XFF350 Navigator Lift-Away NV350, NV351, NV352 Replacement Filter Set, 1 Felt + 1 Foam$29.99Fits Shark Navigator Lift Professional Away Models; NV355, NV356, NV356E, NV357 Learn More
Genuine Shark Euro-Pro X1725QN 4.8V 1.3Ah Ni-Cad Replacement OEM Battery, Fits Shark Cordless Sweepers, Including Models V1930 V1700Z$21.41Genuine Shark Euro-Pro Replacement Ni-Cad battery for Shark Cordless Sweeper models V1700Z, V1930, Part Number X1725QN. Battery has a wire lead and plastic sheath included, and has numbers X1725QN 4.8V 1.3Ah by Euro-Pro. Genuine OEM Shark replacement battery. Learn More
Shark XFH400 Rotator Professional with XL Reach NV400 Exhaust HEPA Filter, OEM.$29.53This is a genuine Euro-Pro Shark Rotator Professional With XL Reach NV400 Exhaust HEPA Filter Cartridge. This is the plastic circular HEPA filter, which is accessed by unscrewing the bottom red grate, and removing the filter cage. Shark part number XFH400. Its recommended that this filter be replaced once every 12 months. Keep your generous Shark Rotator Professional warranty USE ONLY OEM SHARK FILTERS Learn More
Shark Rotator NV450 XL Professional With Reach Bagless Upright Replacement HEPA Filter Part XHF450$17.18This is a genuine Euro-Pro Shark Rotator Pro with XL Reach NV450 replacement True HEPA Cartridge Replacement Filter, Part Number XHF450. Recommended to be replaced every 6-12 months depending on usage and how active the home is. Genuine OEM Shark Euro-Pro Filter, Use Only Shark Filters to Keep your generous Euro-Pro Shark Warranty Learn More
Shark XFF400 Rotator Professional Replacement Filter Kit, Includes 1 Foam, 1 Felt Filter$16.72This is a genuine Shark OEM XFF400 Filter Kit, which includes 1 Foam and 1 Felt filter. Genuine Shark OEM Filter part number XFF400 and fits Shark Rotator Professional, Shark Rotator Professional with XL reach, and Shark Rotator Professional Lift-Away Upright Vacuums. 2 Filters included in each package. Firs Shark Rotator Upright models NV402 Learn More
Results 1 - 19 of 19

subset: commoncrawl


text:
Log inRegister or subscribe
Reflecting with de Bono's thinking hatsA selection of questions to encourage reflection using the de Bono thinking hats model.
See more resources: Resource templates
Log in to love this resource
Log in to share this resource
Lenny Sky
We are a secondary school in Australia trying to promote more student reflection. This is a great way of ensuring students develop broad thinking - and I love deBono!
Stephanie Hamman
Thank you for the comment! deBono hits Australia!
Review this resource...
Latest resources
Spot the difference!
Creative writing (KS4)
Angel versus Alec
Tess of the D'Urbervilles by Thomas Hardy
Different interpretations of literary texts
Approaches to literature
Working in association with NATE
SPECIAL OFFER: 10% off NATE membership fees for Teachit subscribers. Read more ...


text:
LEGALS: Craig Peterson, WSB #15935 Tiffany Owens, WSB #42449 Kingston Bowen, WSB #46688 Shaun Campbell, WSB #47863 Robinson Tait, P.S. 710 Second Avenue, Suite 710 Seattle, WA 98104 Phone: (206) 676-9640 Fax: (206) 676-9659 Email: cpeterson@ robinsontait.com Email...More info Email a friend
LEGALS: IN THE SUPERIOR COURT OF THE STATE OF WASHINGTON IN AND FOR THE COUNTY OF BENTON In the Matter of the Estate of: MITCHELL V. A. CAMPBELL, Deceased. NO. 15-4-00296-6 NOTICE TO CREDITORS RCW 11.40.030 The Personal Representative named below has been appointed...More info Email a friend
LEGALS: Notice of Intent Washington State Department of Ecology's Construction Stormwater General Permit NOTICE IS HEREBY GIV- EN That the Washington State Department of Transportation - South Central Region, 2809 Rudkin Rd Union Gap, WA 98903, is seeking coverage...More info Email a friend
LEGALS: Notice to Contractors Yakima Valley Community College is developing a roster of qualified contractors who are interested in bidding Small Public Works projects for 2015-2016. Under the guidelines of the State of Washington's Department of Enterprise Services...More info Email a friend
PUBLIC NOTICES: A-Z TOWING ABANDONED VEHICLE AUCTION Friday 7/10/15, 2pm. Public Viewing,11:00 a.m. 1401 W Kenn Ave, Kenn. 3 Vehicles in Auction. (509)585-8000More info Email a friend
LEGALS: Notice of Wine Auction Date of Auction: Friday, July 31, 2015 Time: 1:00 p.m. Location: Americold Logistics, 1115 W. Rose St., Walla Walla, WA 99362 Auction Type: Live auction (bids may be placed by phone or email) Seller: Wallula Gap Vineyards, LLC Contact...More info Email a friend
LEGALS: Finley School District #53 has completed the 2015-2016 Budget. The Board of Directors will meet on Monday, July 20, 2015 at 7:00 p.m. in the Finley School District Board Room for the purpose of fixing and adopting the 2015-2016 Budget. Any interested taxpayers...More info Email a friend
LEGALS: INVITATION TO BID NOTICE TO CONTRACTORS Sealed proposals will be received by CKJT Architects at the Architect's office, 128 Vista Way, Kennewick, Washington 99336, (phone 509-783-5444), for the construction of the PSD Freezer Projects - 2015. Sealed bid...More info Email a friend
LEGALS: Notice of Changes to City of Pasco Standard Specifications and Drawings This is to notify you that the City of Pasco has made changes to the City's Standard Drawings and Amend- ments to the Standard Specifications, effective July 1, 2015. The updated documents...More info Email a friend
LEGALS: NOTICE OF PUBLIC HEARING PLEASE TAKE NOTICE that the Pasco School District has filed a petition (MF #SP 2015-002) requesting a special permit for redevelopment of the Stevens Middle School site on the following property: Legal: A portion of the SW Quarter...More info Email a friend


text:
In this way, bisexual is code for libertine, which is something else altogether.
She sought to arouse what attention she could by running for governor as the most libertine of libertarians.
The pill occupies the strange middle ground where the libertine drug culture meets high-stress study culture.
late 14c., "a freedman, an emancipated slave," from Latin libertinus "member of a class of freedmen," from libertus "one's freedmen," from liber "free" (see liberal). Sense of "freethinker" is first recorded 1560s, from French libertin (1540s) originally the name given to certain Protestant sects in France and the Low Countries. Meaning "dissolute or licentious person" first recorded 1590s; the darkening of meaning being perhaps due to misunderstanding of Latin libertinus in Acts vi:9. As an adjective by 1570s.
found only Acts 6:9, one who once had been a slave, but who had been set at liberty, or the child of such a person. In this case the name probably denotes those descendants of Jews who had been carried captives to Rome as prisoners of war by Pompey and other Roman generals in the Syrian wars, and had afterwards been liberated. In A.D. 19 these manumitted Jews were banished from Rome. Many of them found their way to Jerusalem, and there established a synagogue.


text:
OTC Guide
Community Pharmacist
Hospital Pharmacist
Student Pharmacist
Pharmacy Technician
Specialty Pharmacist
Resource Centers
Acid Reflux
Acute Coronary Syndrome
Atrial Fibrillation
Bipolar Disorder
Cardiovascular Health
Cough and Cold
Heart Failure
Hepatitis C
Infectious Disease
Pain Management
Pharmacy Management
Type 2 Diabetes
Vitamins and Supplements
Women's Health
Continuing Education
ActHIB Component of 2-Vial Pentacel is Repeatedly Missed
Michael J. Gaunt, PharmD
Published Online:
Friday, January 11, 2013
Follow Pharmacy_Times:
This childhood vaccine given as 1 shot requires mixing of 2 components, leading to omission errors.
Pentacel is a multicomponent vaccine for active immunization against diphtheria, tetanus, pertussis, poliomyelitis, and invasive disease due to
Haemophilus influenzae
type b. It is for use in children 6 weeks through 4 years of age and provides the convenience of multiple vaccines in 1 shot.
It is a 2-vial vaccine product, however, that requires mixing of the 2 components before administration to children (Figure). The vaccine is available in a 5-dose carton containing diphtheria and tetanus toxoids, acellular pertussis adsorbed, inactivated poliovirus (DTaP-IPV) liquid component vials (blue-capped vial) used to reconstitute each single-dose vial of the lyophilized
H influenzae
type b vaccine (ActHIB) component (green-capped vial).
A Common, Preventable Error
Again and again, The Institute for Safe Medication Practices (ISMP) has received reports involving children who must return to their doctor's office with their parents in order to receive the inadvertently omitted
H influenzae
type b component, with some cases involving numerous patients.
In 1 case, only 1 component of the vaccine product, the DTaP/IPV portion, was administered to the child, not the Hib (
Haemophilus b conjugate
) portion. The provider later continued the series and the child did not experience any harm. The error was discovered during an inventory of the vaccines. In another case, a nurse checking inventory opened a carton and found an extra green-capped vial. It was later learned that another nurse failed to use the DTaP-IPV component to dilute the ActHIB in the other vial.
One reason these errors may occur is that the DTaP/IPV component carries the brand name Pentacel, whereas the Hib component is labeled ActHIB, a totally different brand name. Unless the person administering the vaccine is familiar with the product and takes the time to read the labeling, which indicates the 2 must be mixed, the person could easily think the vial labeled Pentacel is all that is needed. ISMP contacted the company and the FDA about this and also suggested enhancing the labeling to call attention to the need to mix the 2 components.
Safe Practice Recommendations
One report submitted to ISMP indicated that the clinic is now keeping the vials of the DTaP-IPV liquid component (blue-capped vial) and ActHIB component (green-capped vial) together using a rubber band to avoid this mistake in the future.
Pharmacies, clinics, and physician offices might want to consider this or another process to keep the vials together (eg, placing the 2 vials in a zipper closure bag) and the use of an auxiliary label for the carton to remind staff to use both vials.
To confirm administration of both components, staff should also make sure the NDC number for each vial has been documented in the vaccine log before administration. Documenting the actual administration of the vaccine should always occur after it is given.
ISMP has launched its third national patient safety reporting program, the ISMP National Vaccine Errors Reporting Program (ISMP VERP). ISMP VERP (http://verp.ismp.org) captures the unique causes and consequences of vaccine-related errors. The program was designed with the assistance of the California Department of Public Health.
As with all ISMP reporting programs, reporter information is confidential. Reports submitted to ISMP VERP will be shared with the FDA and the Centers for Disease Control and Prevention. They also will be forwarded to the vaccine manufacturer when applicable. Please share reports of vaccine-related errors, in confidence, with ISMP.
Dr. Gaunt is a medication safety analyst and the editor of ISMP Medication Safety Alert! Community/ Ambulatory Care Edition.
Related Articles
Pharmacist-Provided Flu Shots Please Patients
Patients are highly satisfied with the influenza vaccines pharmacists are providing in community pharmacies.
Mental Recess: Voice Your Value
Exams, all-nighters, celebrations, vaccinations, rotations: these are just a few of the things students can expect in their journey from pharmacy student to pharmacist.
Pharmacy Students Support Medicine for Mali
Students at Drake University College of Pharmacy and Health Services are providing care beyond the confines of Des Moines, Iowa.
FDA Approves Children's DTaP-IPV Vaccine
The FDA today approved a vaccine for active immunization against diphtheria, tetanus, pertussis, and poliomyelitis for children aged 4 to 6 years.
Latest Issues
MJH Associates
American Journal of Managed Care
MD Magazine
Specialty Pharmacy Times
Targeted Oncology
About Us
Contact Us
Terms & Conditions
Press Room
Intellisphere, LLC
666 Plainsboro Road
Building 300
Plainsboro, NJ 08536
Copyright PharmacyTimes 2006-2015
Intellisphere, LLC. All Rights Reserved.