- Email: [email protected]
CAD in technical security: A knowledge-based approach
Expert Systems With Applications, Vol. 4, pp. 63--68, 1992
0957--4174/92 $5.00 + .00 © 1991 Pergamon Press pie
Printed in the USA.
CAD in Technical Security: A Knowledge-Based Approach M.
KANTARD~.I(~,
M.
JEFTOVI(~,
A.
FILIFOVI(~,
H.
GLAVI(~,
D. GAJ[C, N. MILI(~I(~
Faculty of Electrical Engineering. Ekktrotehnicki fakuitet Sarajevo, Topli6ka bb, 71000 Sarajevo, Yugoslavia
Abstract--In this article we present a realization of a software package for computer-aided design (CAD) of an object and area technical security system. The system provides aid in various phases of design process: from technical security system component choice, security system configuration, and process simulation to project documentation support. A built-in knowledge base supports the design process in the phase of components choice and configuration. The package is tested on several existing objects.
1. I N T R O D U C T I O N
1.2. W h y AI?
THIS ARTICLE presents a knowledge-based CAD software package for technical security systems (CSP-TSS). The CSP-TSS is a result o f long-range research in the Laboratory for Electronics and C o m p u t e r Technique in the Faculty of Electrical Engineering in Sarajevo. The number of experts in this area have been consulted in order to formalize and use their knowledge and experience in an appropriate knowledge base as a constituent part of the C A D system.
After serious and detailed consultations and interviews with a n u m b e r of experts in TSS design, we have found that the type of knowledge the experts shared was a n u m b e r of personal experiences in construction of some existing TSS. The stories o f problems that arose under certain environmental conditions were like the following: • . . once there were some high trees nearby the area where we had placed sensors, and it took us a long time to find out that these trees were the cause of too frequent false alarms, whenever there was some wind . . . .
1.1. CSP-TSS Goals An analysis o f a design process o f computer-based object and area technical security systems (TSS) introduced the following requirements on a CAD system in this area (Hahn, 1979; Healy, 1983; Kurai, 1983): • TSS component choice aid: sensors, communication lines, rails, control stations, etc. • C o m p o n e n t s connection aid to define the final TSS architecture • Evaluation o f performance of the designed TSS, based on simulation of processes in this system, as well as evaluation o f efficiency and reliability parameters • Aid in a choice o f a particular TSS c o m p o n e n t manufacturer, considering availability of the component, price, delivery time, and maintenance • Aid in, and monitoring of a documentation design process • Capability of an education o f C A D system users, as well as novices in the area of TSS
On one hand, these experiences were extremely difficult to describe by means of mathematical modeling, but on the other hand, they were very suitable to formalization by means of I F - T H E N rules. Thus the conclusion arose that AI methods are simply unavoidable if one wants to create a valid tool for TSS design aid. The other obvious lead toward knowledge-based implementation of the module for TSS design aid was the fact that every time we had contacted a new expert, we encountered a new type of problem. In other words, the module must be quite open, suitable to be changed and improved as the new experiences are gathered. The main indications of the necessity for implementation of AI methods in the module for TSS design aid were: • Knowledge with an unclear structure, based on experience of experts, that were difficult to model • Need for an expandable system, adaptable to new experiences • Knowledge suitable for formalization by means of I F - T H E N rules
Requests for reprintsshould be sent to M. Kantard~i6,Ekktrotehnicki fakultet Sarajevo, Topli~kabb, 71000 Sarajevo, Yugoslavia. 63
64
M. Kantard~tc "'* et al.
INTEGRATIONMODULE
~
EDUCATION I
DESIGN
[--
I
I
I
DOCUMENTATIONDESIGN FIGURE 1. CSP-TSS software architecture.
2. ARCHITECTURE OF CSP-TSS In order to address the tasks listed in Section 1.1., the CAD system is based on tools and methods concerning areas of artificial intelligence, computer graphics, databases, and computer-user interaction. The CSP-TSS is realized in a modular manner, with a large interaction degree between modules. The global architecture of the system is given in Figure 1.
2.1.1. Formal Knowledge Description. The knowledge base is divided into two separate parts, due to the DIPSY-E manner of knowledge formalization (Filipovi6 et al., 1986; Kantard~i6, 1986), one containing the facts that describe the current state of the problem, and the other containing rules describing actions to be taken in a given state. The facts in this particular case are some "objects" with their attributes, describing types of TSS components, characteristics of the object to be protected by TSS, characteristics of an environment, etc. For example, a particular object is in a climate where snow, rain, and fog are usual, and it has a railroad and forest nearby. In DIPSY-E language, these facts are described as:
geophysical_ conditions (climate_conditions = { snow rain fog }, close_objects = { railroad forest } )
2.1. Module for Technical Security System Design Aid For the reasons given in Section 1.2., the module for TSS design aid realization is based on the knowledge of experts in this area. This module is implemented by means of an expert system development tool DIPSYE, also a product of our laboratory (Filipovi6, Kantard~i6, & Osmanagi6, 1986; Kantard~i6, 1988)using a forward-chaining inference engine (FCIE) supported by the tool. The knowledge base is connected to the manufacturers-products database, which can be approached independently, as a submodule of this module. Figure 2 shows an overall architecture of the design aid module.
The most important objects (in the sense of language) in this base are ground and geophysical_conditions describing environmental characteristics of the area, exists describing the existing parts of the technical security system, and project_.solution where the system incrementally defines the solutions for the security system being analyzed and designed. To show the rule formalism, the following rule describes the statement: • . . If there is no snow around, and the ground is not swamp, it is possible to use sensor X . . . . More formally, in DIPSY-E language this means that if an attribute climate_conditions of an object
I I
COMPONENTS/ MANUFACTURERS DATA BASE MANAGEMENT
TSS DESIGN KNOWLEDGE BASE MANAGEMENT
1 COMPONENTS/ MANUFACTURERS DATA BASE I
TSS DESIGN KNOWLEDGE BASE
' I
CHOICE OF A MANUFACTURER '
L I CONFIGURATION OF A TSS
CONFIGURED TSS COMPONENTS AND RECOMENDATIONS FIGURE 2. Overall architecture of the design aid module.
CAD in Technical Security
65
geophysicaL_conditions does not contain a value snow, and a kind of land is not swampy, a sensor__type_x can be added to the set of sensors that can be used:
In DIPSY-E this is written as: RULE:initiaL_input IF
IF geophysical_conditions (climate_conditions :!snow)
THEN read (t _securitylevel,[ x ], { low medium high } );
AND
read(t_ground_wired,[answer ], { yes no } );
ground(kind swampy)
read(t_ground_type,[ground_type ], { normal termite aggressive } );
THEN value
value
exists(possible_to_use :+ { sensor_type_x } )
project__solution(security_level := [x],
2.1.2. Organization of the Rule Base• The DIPSY-E tool offers several search and conflict resolution strategies (Kantard~i6, 1986; Kantard~i6, Glavi6, & Filipovi6, 1988). A variant of the FCIE, which divides the rule base into several segments, each dealing with a particular subproblem, is taken for this particular application. The flowchart of the segments is given in Figure 3, whereas the following is a brief description of each segment with a sample rule for that segment. Reading Characteristics. The first segment interactively compiles the data necessary to determine all the constraints for the TSS implementation. The user is asked about technical characteristics of the (existing or future) TSS, geographical, climate and environmental characteristics of the location. The sample rule formally represents the notion that • . . before you start to reason anything about the protection system, you should know what level of protection you need for the object, is the object ground-wired, what is the ground like. . . .
I Common environment characteristics[ Section environment characteristics [ I
Choice of sensors
[
ground_wired := [answer]); value ground(ground_type := [ground_.type]) This rule (unconditionally executed in the beginning) reads some initial values. The format of the read procedure is read (text _name,[ variable ] ,range) where text_._name designates the text being written to a display, giving necessary explanations to the user, [variable] contains the value red, and range restricts the possible values to be assigned to the variable. In the example, the first read displays text named t_security_level and reads value of the variable [x], which can be only one to come from the set { low medium high }. Characteristics of Sections. The next segment examines the same group of problems, but in the details connected to each of the sections (the overall TSS is always divided into sections, each covering the part with similar characteristics, e.g. the fiver side of the object, the road side . . . . ). The sample rule says that • . . for each section you first decide whether it is a fence o r a gate and of what length it is. . . . In DIPSY-E: RULE:section_type IF
[
Choice of fences
[
I
Choice of connections
[
THEN read(t_section_type,[ x], { fence gate } ); read (t_section_length,[ section_length ] ,0<999); value
[ Overall contib~trationand report I FIGURE 3. Organization of the rule base.
project_solution (section_type := Ix], section.__length := [ section.length ])
66
M. Kantard~i~ et al.
This rule reads the type and the length of each section. Choice of Components. The following segments of the system select types of components suitable for the particular TSS section, relying on information gathered in previous segments. The sample rules in the segments dealing with fence, sensors, and connections choice are, respectively: RULE: choice_of_fence IF exists( fence = no, project_fence = no) AND project_solution (object__type=stationary) T H E N write(fence_recommendation ); value project __.solution ( fence = strained__ material ) saying that if there is no fence, neither in project, and
the object is stationary, then some recommendation is displayed and in project solution is written that thefence shouM be of strained material,"
into the project documentation. An example of a typical recommendation is as follows:
Since the object is surrounded with bushes and high grass, which might cause false alarms, if you decide to use radar_beside_the fence, recommendation is: • to remove bushes on both sides of the fence, in the area of 2-5 meters • to mow the grass regularly during the system use All these section dedicated segments, starting with the second, are members of the structure in DIPSY-E called the "supersegment." This structure enables groups of segments to be examined repeatedly. Summary Recommendation. Finally, the last segment groups all the generated data into the summary recommendation and displays it in documentation form. The sample rule finds out all the sensors that can be installed both on the fence and on the gates: RULE: p IF exists( f _ s = [x], g_s= [y]) T H E N value exists(p_ f _ s : = [x],
RULE: geophone2
p _ f _ s : * [y])
IF exists (another__x._line = yes) AND project___solution (object_type = stationary) T H E N value exists(possibility phone_in_l }
:+
{ g e o p h o n e _ o n _ f geo-
saying that if there & another sensory line and object
is stationary, then it is possible to add geophones on the fence and in the land to the set of possible sensors; RULE: cable_a IF ground (type = aggressive ) T H E N write ( _ c a b l e _ a ) displaying a recommendation concerning cables laid in the aggressive ground. These segments also take care of interference among different elements of the security system, taking care to avoid combinations that can produce undesirable side effects (e.g., some sensors do not go well with some fences). These segments also give recommendations on some special conditions for implementation of particular components for each of the sections (e.g., one must not have a high snow when using particular types of sensors; if so, the snow must be removed regularly). Those recommendations could be also directly built
calculating the resulting set of sensors as the intersection (: * operation symbol) of the set of sensors for fence, [x], and the set of sensors on the gates, [y]. 2.1.3. Manufacturers~Products Database. Although the previous submodule uses technoeconomical data on a high level (technical classes of components, economical aspect contained in possible three levels of protection--high, medium, or low), the manufacturers/products database contains data about particular products available on the market, along with their producers. It uses the results of the knowledge-based analysis and, for each recommended component, it can retrieve information the manufacturers and products databases, as well as a choice of a manufacturer considering the criteria of price, delivery time, maintenance, availability, component reliability, etc. These criteria are effective if the previous submodule has generated alternatives for some components. This submodule can also be approached independently, with no previous activation of an ES. 2.2. Simulation This module provides an aid in the following points of the TSS design process: * Creation of a model of a computer based technical security system
CAD in Technical Security
67
Process simulation concerning failures and alarms enabling detection of faults in the defined technical security system architecture • Chronological evidence of events during the simulation process • Statistic analysis of failures alarms and false alarms This is the most hardware-dependent module, made to be used with the TEK 4111 high resolution graphic terminal. The user is provided with a multiwindow menu screen, shown in Figure 4. The map of the TSS to be simulated is drawn by means of a mouse and icon types displayed on the left side of the screen. All the created models of TSS are stored into a model base, to be recalled when needed. The simulated events are stored in an event base. The bases can be used for report generation. Reports can be generated either periodically or by request and can be statistically analyzed to create input data for the reliability estimation module (Section 2.3.). •
2.3. Reliability and Efficiency Estimation The algorithm of this module relies on the data accumulated in the design (Section 2.1.) and the simulation (Section 2.2.) phase. In addition it uses some technical/ economical aspects of price, quality, and level of importance of the object (Morton, 1984; Henley, 1985). Functional interconnections of the system and the element reliability levels can be described by the following (we do not intend to give exact functionality of the symbols f a n d F, but rather to give only a symbolic description of dependencies):
M = f ( F ( r i , ti, N), u(ri, ti, 6, T~, Tp, N ) )
SENSOR
where M = system reliability indicator F(ri, ti, N) = functional interpretation of the system structure and interconnections time, ti ri = indicates the i th element reliability N = number of elements within the system U = influence of the exploitation factors = technical maintenance amount Tp = technical maintenance period T~ = time of the diminished availability of the system, due to technical maintenance operations The module enables analysis of reliability and efficiency parameters related to various changes of input parameters. Accordingly, it is possible to notice system failures, redundancy, influence of system structure change and component change (Chery, 1986). This module can also be used with no interaction to other modules to test previously implemented technical security systems.
2.4. Documentation This module is based on principles of commonly known text processors (Kantard~i6 & Kova6evi6, 1985), emphasizing comfortable computer-user interaction as follows: • Simple creation and connection of graphic and text documentation components • Possibilities to work with standard, software-defined forms
OBJECT : TEST
l--I TERMINAL
0 CENTRAL STATION~ COMMUNICATION LINES ~ FENCE EXECUTIVE TERMINAL ~ BARRIER
COMMUNICATIONWINDOW FIGURE 4. One of the screens during the simulation.
68
M. KantardzTd et aL
• Extended possibilities to work with document archives o f former implemented technical security system designs • Possibility of using the archives during the new design documentation realization
2.5. Education This module describes the CAD system and manner of its use throughout comfortable menus. In fact, this is on-line user documentation. The module is open to modifications, thus it is easy to include any changes on the CSP-TSS. It is possible to add new text files and appropriate m e n u s that enable the system to be used in other similar areas (sensors, communication, etc.).
3. DESIGN PROCESS USING C S P - T S S Now we will try to give an overview of global steps in completion of a project task, using CSP-TSS. The first step is to gather all the relevant data about the object, its environment, climate, ground type, and quality and the basic requirements on TSS being designed. This is the preparation step, and it does not involve direct CSPTSS use. The CSP-TSS session starts with the module for the TSS design aid (Section 2.1.). First, the elements of TSS are chosen and connected (supposedly with alternatives) in interaction with the knowledge base (Section 2.1.1.), and then the components are defined using the products database (Section 2.1.2.). After the system is preliminarily designed, the simulation is performed (Section 2.2.) in order to test the functionality of the TSS and gain statistical information (if these are not presented by the producer) needed in the next step. The results of the simulation are passed to the reliability estimation module (Section 2.3.) where we look for a confirmation of the TSS features. The unsatisfactory results can cause a loop to the design step or to the simulation step, using alternative set of components. After the system is "fine tuned" in the last three steps, the module for documentation creation is used (Section 2.4.) as a final step in the design process. The education module (Section 2.5.) can be used to train the future operators of the TSS. 4. C O N C L U S I O N The described implementation of a CAD software package for technical security systems (CSP-TSS) has been an experience in two ways: first, it was the first use o f the DIPSY-E tool in area of design problems; second, it was a large project in creating the complete CSP-TSS. Functional requirements of the CSP-TSS
determined the necessary hardware components, as well as corresponding software. Computer configuration is based on the microprocessor M68020 also containing T E K high resolution graphic terminal along with the mouse and tablet. The software environment needed for CSP-TSS is a U N I X operating system, a compiler for programming language C and Pascal, and the ES development tool DIPSY-E. The choice of programming languages C and Pascal for realization of CSP-TSS is based on the fact that those languages are fairly c o m m o n l y used on microcomputers. This provides, to a certain level, portability of realized software to other computer configurations. For the results, it is sufficient to mention that the complete CSPoTSS is in operation, and the users are evidently generally satisfied. Yet, together with the results, limitations arise. Most important for us was learning the limitations of DIPSY-E as a shell. Some approaches in the user interface of the tool appeared to be inadequate, as well as some language constructions. Thus we have gathered significant and important information on how to improve DIPSY-E (the described system is developed on DIPSY-E V2.x; right now we are working on the V3.x version ).
REFERENCES Barnard, R. (1981 ). Intrusion detection systems. London: Butterworth. Chery, D.D. (1986). Total facility control. London: Butterworth. Filipovi6, A., Kantard~i6, M., & Osmanagie6, S. (1986). Syntactic editor DIPSY-E.Conference Proceedings Computer on University, Cavtat, Yugoslavia. Hahn, S. (1979). Modern electronic security systems. New York. Healy, R. (1983). Design for security. New York: Wiley. Henley, E.J., & Kumamoto, K. (1985). Design for reliability and safety Control. Simp. Series No. 92. PSE 85. Cambridge,England. Kantard~i6, M. (1986). The inference engine in the DIPSY-E development tool for expert systems. Conference on Application of Artificial Intelligence IV. Innsbruck, Austria. Kantard~i6, M., & Kova~vi6, S. (1985). Intelligentform management system. Networks in office automation. North-Holland. Kantard~.i6, M., Glavi6, H., & Filipovi6,A. ( 1988). Computer aided designof technical securitysystems:Approachbasedon knowledge base. Conference Proceedings ETAN'88, Sarajevo,Yugoslavia. Kantard~i6, M., Jeftovi6,M., Glavi6,H., et al. (1990). Expertsystem for technical security systemdesign, lITT Conference "EXPERSYS. ""Grenoble, France. Kantard~i~, M., Jeftovi6, M., Glavi6, H., et al. (1990). A comprehensiveenvironment for computeraid in technicalsecuritysystem design. Proceedings of the International Conference "DEXA '90." City: Springer-Verlag. Kurai, L. (1983). Model for analysis of alarm systems efficiency. Alarm 1-2(2). Morton, H.E. (1984). SENTRAX l--An integrated securitydisplay and control system. 1984 Carnaham Conference on Security Technology, Centacky, Yugoslavia.
0957--4174/92 $5.00 + .00 © 1991 Pergamon Press pie
Printed in the USA.
CAD in Technical Security: A Knowledge-Based Approach M.
KANTARD~.I(~,
M.
JEFTOVI(~,
A.
FILIFOVI(~,
H.
GLAVI(~,
D. GAJ[C, N. MILI(~I(~
Faculty of Electrical Engineering. Ekktrotehnicki fakuitet Sarajevo, Topli6ka bb, 71000 Sarajevo, Yugoslavia
Abstract--In this article we present a realization of a software package for computer-aided design (CAD) of an object and area technical security system. The system provides aid in various phases of design process: from technical security system component choice, security system configuration, and process simulation to project documentation support. A built-in knowledge base supports the design process in the phase of components choice and configuration. The package is tested on several existing objects.
1. I N T R O D U C T I O N
1.2. W h y AI?
THIS ARTICLE presents a knowledge-based CAD software package for technical security systems (CSP-TSS). The CSP-TSS is a result o f long-range research in the Laboratory for Electronics and C o m p u t e r Technique in the Faculty of Electrical Engineering in Sarajevo. The number of experts in this area have been consulted in order to formalize and use their knowledge and experience in an appropriate knowledge base as a constituent part of the C A D system.
After serious and detailed consultations and interviews with a n u m b e r of experts in TSS design, we have found that the type of knowledge the experts shared was a n u m b e r of personal experiences in construction of some existing TSS. The stories o f problems that arose under certain environmental conditions were like the following: • . . once there were some high trees nearby the area where we had placed sensors, and it took us a long time to find out that these trees were the cause of too frequent false alarms, whenever there was some wind . . . .
1.1. CSP-TSS Goals An analysis o f a design process o f computer-based object and area technical security systems (TSS) introduced the following requirements on a CAD system in this area (Hahn, 1979; Healy, 1983; Kurai, 1983): • TSS component choice aid: sensors, communication lines, rails, control stations, etc. • C o m p o n e n t s connection aid to define the final TSS architecture • Evaluation o f performance of the designed TSS, based on simulation of processes in this system, as well as evaluation o f efficiency and reliability parameters • Aid in a choice o f a particular TSS c o m p o n e n t manufacturer, considering availability of the component, price, delivery time, and maintenance • Aid in, and monitoring of a documentation design process • Capability of an education o f C A D system users, as well as novices in the area of TSS
On one hand, these experiences were extremely difficult to describe by means of mathematical modeling, but on the other hand, they were very suitable to formalization by means of I F - T H E N rules. Thus the conclusion arose that AI methods are simply unavoidable if one wants to create a valid tool for TSS design aid. The other obvious lead toward knowledge-based implementation of the module for TSS design aid was the fact that every time we had contacted a new expert, we encountered a new type of problem. In other words, the module must be quite open, suitable to be changed and improved as the new experiences are gathered. The main indications of the necessity for implementation of AI methods in the module for TSS design aid were: • Knowledge with an unclear structure, based on experience of experts, that were difficult to model • Need for an expandable system, adaptable to new experiences • Knowledge suitable for formalization by means of I F - T H E N rules
Requests for reprintsshould be sent to M. Kantard~i6,Ekktrotehnicki fakultet Sarajevo, Topli~kabb, 71000 Sarajevo, Yugoslavia. 63
64
M. Kantard~tc "'* et al.
INTEGRATIONMODULE
~
EDUCATION I
DESIGN
[--
I
I
I
DOCUMENTATIONDESIGN FIGURE 1. CSP-TSS software architecture.
2. ARCHITECTURE OF CSP-TSS In order to address the tasks listed in Section 1.1., the CAD system is based on tools and methods concerning areas of artificial intelligence, computer graphics, databases, and computer-user interaction. The CSP-TSS is realized in a modular manner, with a large interaction degree between modules. The global architecture of the system is given in Figure 1.
2.1.1. Formal Knowledge Description. The knowledge base is divided into two separate parts, due to the DIPSY-E manner of knowledge formalization (Filipovi6 et al., 1986; Kantard~i6, 1986), one containing the facts that describe the current state of the problem, and the other containing rules describing actions to be taken in a given state. The facts in this particular case are some "objects" with their attributes, describing types of TSS components, characteristics of the object to be protected by TSS, characteristics of an environment, etc. For example, a particular object is in a climate where snow, rain, and fog are usual, and it has a railroad and forest nearby. In DIPSY-E language, these facts are described as:
geophysical_ conditions (climate_conditions = { snow rain fog }, close_objects = { railroad forest } )
2.1. Module for Technical Security System Design Aid For the reasons given in Section 1.2., the module for TSS design aid realization is based on the knowledge of experts in this area. This module is implemented by means of an expert system development tool DIPSYE, also a product of our laboratory (Filipovi6, Kantard~i6, & Osmanagi6, 1986; Kantard~i6, 1988)using a forward-chaining inference engine (FCIE) supported by the tool. The knowledge base is connected to the manufacturers-products database, which can be approached independently, as a submodule of this module. Figure 2 shows an overall architecture of the design aid module.
The most important objects (in the sense of language) in this base are ground and geophysical_conditions describing environmental characteristics of the area, exists describing the existing parts of the technical security system, and project_.solution where the system incrementally defines the solutions for the security system being analyzed and designed. To show the rule formalism, the following rule describes the statement: • . . If there is no snow around, and the ground is not swamp, it is possible to use sensor X . . . . More formally, in DIPSY-E language this means that if an attribute climate_conditions of an object
I I
COMPONENTS/ MANUFACTURERS DATA BASE MANAGEMENT
TSS DESIGN KNOWLEDGE BASE MANAGEMENT
1 COMPONENTS/ MANUFACTURERS DATA BASE I
TSS DESIGN KNOWLEDGE BASE
' I
CHOICE OF A MANUFACTURER '
L I CONFIGURATION OF A TSS
CONFIGURED TSS COMPONENTS AND RECOMENDATIONS FIGURE 2. Overall architecture of the design aid module.
CAD in Technical Security
65
geophysicaL_conditions does not contain a value snow, and a kind of land is not swampy, a sensor__type_x can be added to the set of sensors that can be used:
In DIPSY-E this is written as: RULE:initiaL_input IF
IF geophysical_conditions (climate_conditions :!snow)
THEN read (t _securitylevel,[ x ], { low medium high } );
AND
read(t_ground_wired,[answer ], { yes no } );
ground(kind swampy)
read(t_ground_type,[ground_type ], { normal termite aggressive } );
THEN value
value
exists(possible_to_use :+ { sensor_type_x } )
project__solution(security_level := [x],
2.1.2. Organization of the Rule Base• The DIPSY-E tool offers several search and conflict resolution strategies (Kantard~i6, 1986; Kantard~i6, Glavi6, & Filipovi6, 1988). A variant of the FCIE, which divides the rule base into several segments, each dealing with a particular subproblem, is taken for this particular application. The flowchart of the segments is given in Figure 3, whereas the following is a brief description of each segment with a sample rule for that segment. Reading Characteristics. The first segment interactively compiles the data necessary to determine all the constraints for the TSS implementation. The user is asked about technical characteristics of the (existing or future) TSS, geographical, climate and environmental characteristics of the location. The sample rule formally represents the notion that • . . before you start to reason anything about the protection system, you should know what level of protection you need for the object, is the object ground-wired, what is the ground like. . . .
I Common environment characteristics[ Section environment characteristics [ I
Choice of sensors
[
ground_wired := [answer]); value ground(ground_type := [ground_.type]) This rule (unconditionally executed in the beginning) reads some initial values. The format of the read procedure is read (text _name,[ variable ] ,range) where text_._name designates the text being written to a display, giving necessary explanations to the user, [variable] contains the value red, and range restricts the possible values to be assigned to the variable. In the example, the first read displays text named t_security_level and reads value of the variable [x], which can be only one to come from the set { low medium high }. Characteristics of Sections. The next segment examines the same group of problems, but in the details connected to each of the sections (the overall TSS is always divided into sections, each covering the part with similar characteristics, e.g. the fiver side of the object, the road side . . . . ). The sample rule says that • . . for each section you first decide whether it is a fence o r a gate and of what length it is. . . . In DIPSY-E: RULE:section_type IF
[
Choice of fences
[
I
Choice of connections
[
THEN read(t_section_type,[ x], { fence gate } ); read (t_section_length,[ section_length ] ,0<999); value
[ Overall contib~trationand report I FIGURE 3. Organization of the rule base.
project_solution (section_type := Ix], section.__length := [ section.length ])
66
M. Kantard~i~ et al.
This rule reads the type and the length of each section. Choice of Components. The following segments of the system select types of components suitable for the particular TSS section, relying on information gathered in previous segments. The sample rules in the segments dealing with fence, sensors, and connections choice are, respectively: RULE: choice_of_fence IF exists( fence = no, project_fence = no) AND project_solution (object__type=stationary) T H E N write(fence_recommendation ); value project __.solution ( fence = strained__ material ) saying that if there is no fence, neither in project, and
the object is stationary, then some recommendation is displayed and in project solution is written that thefence shouM be of strained material,"
into the project documentation. An example of a typical recommendation is as follows:
Since the object is surrounded with bushes and high grass, which might cause false alarms, if you decide to use radar_beside_the fence, recommendation is: • to remove bushes on both sides of the fence, in the area of 2-5 meters • to mow the grass regularly during the system use All these section dedicated segments, starting with the second, are members of the structure in DIPSY-E called the "supersegment." This structure enables groups of segments to be examined repeatedly. Summary Recommendation. Finally, the last segment groups all the generated data into the summary recommendation and displays it in documentation form. The sample rule finds out all the sensors that can be installed both on the fence and on the gates: RULE: p IF exists( f _ s = [x], g_s= [y]) T H E N value exists(p_ f _ s : = [x],
RULE: geophone2
p _ f _ s : * [y])
IF exists (another__x._line = yes) AND project___solution (object_type = stationary) T H E N value exists(possibility phone_in_l }
:+
{ g e o p h o n e _ o n _ f geo-
saying that if there & another sensory line and object
is stationary, then it is possible to add geophones on the fence and in the land to the set of possible sensors; RULE: cable_a IF ground (type = aggressive ) T H E N write ( _ c a b l e _ a ) displaying a recommendation concerning cables laid in the aggressive ground. These segments also take care of interference among different elements of the security system, taking care to avoid combinations that can produce undesirable side effects (e.g., some sensors do not go well with some fences). These segments also give recommendations on some special conditions for implementation of particular components for each of the sections (e.g., one must not have a high snow when using particular types of sensors; if so, the snow must be removed regularly). Those recommendations could be also directly built
calculating the resulting set of sensors as the intersection (: * operation symbol) of the set of sensors for fence, [x], and the set of sensors on the gates, [y]. 2.1.3. Manufacturers~Products Database. Although the previous submodule uses technoeconomical data on a high level (technical classes of components, economical aspect contained in possible three levels of protection--high, medium, or low), the manufacturers/products database contains data about particular products available on the market, along with their producers. It uses the results of the knowledge-based analysis and, for each recommended component, it can retrieve information the manufacturers and products databases, as well as a choice of a manufacturer considering the criteria of price, delivery time, maintenance, availability, component reliability, etc. These criteria are effective if the previous submodule has generated alternatives for some components. This submodule can also be approached independently, with no previous activation of an ES. 2.2. Simulation This module provides an aid in the following points of the TSS design process: * Creation of a model of a computer based technical security system
CAD in Technical Security
67
Process simulation concerning failures and alarms enabling detection of faults in the defined technical security system architecture • Chronological evidence of events during the simulation process • Statistic analysis of failures alarms and false alarms This is the most hardware-dependent module, made to be used with the TEK 4111 high resolution graphic terminal. The user is provided with a multiwindow menu screen, shown in Figure 4. The map of the TSS to be simulated is drawn by means of a mouse and icon types displayed on the left side of the screen. All the created models of TSS are stored into a model base, to be recalled when needed. The simulated events are stored in an event base. The bases can be used for report generation. Reports can be generated either periodically or by request and can be statistically analyzed to create input data for the reliability estimation module (Section 2.3.). •
2.3. Reliability and Efficiency Estimation The algorithm of this module relies on the data accumulated in the design (Section 2.1.) and the simulation (Section 2.2.) phase. In addition it uses some technical/ economical aspects of price, quality, and level of importance of the object (Morton, 1984; Henley, 1985). Functional interconnections of the system and the element reliability levels can be described by the following (we do not intend to give exact functionality of the symbols f a n d F, but rather to give only a symbolic description of dependencies):
M = f ( F ( r i , ti, N), u(ri, ti, 6, T~, Tp, N ) )
SENSOR
where M = system reliability indicator F(ri, ti, N) = functional interpretation of the system structure and interconnections time, ti ri = indicates the i th element reliability N = number of elements within the system U = influence of the exploitation factors = technical maintenance amount Tp = technical maintenance period T~ = time of the diminished availability of the system, due to technical maintenance operations The module enables analysis of reliability and efficiency parameters related to various changes of input parameters. Accordingly, it is possible to notice system failures, redundancy, influence of system structure change and component change (Chery, 1986). This module can also be used with no interaction to other modules to test previously implemented technical security systems.
2.4. Documentation This module is based on principles of commonly known text processors (Kantard~i6 & Kova6evi6, 1985), emphasizing comfortable computer-user interaction as follows: • Simple creation and connection of graphic and text documentation components • Possibilities to work with standard, software-defined forms
OBJECT : TEST
l--I TERMINAL
0 CENTRAL STATION~ COMMUNICATION LINES ~ FENCE EXECUTIVE TERMINAL ~ BARRIER
COMMUNICATIONWINDOW FIGURE 4. One of the screens during the simulation.
68
M. KantardzTd et aL
• Extended possibilities to work with document archives o f former implemented technical security system designs • Possibility of using the archives during the new design documentation realization
2.5. Education This module describes the CAD system and manner of its use throughout comfortable menus. In fact, this is on-line user documentation. The module is open to modifications, thus it is easy to include any changes on the CSP-TSS. It is possible to add new text files and appropriate m e n u s that enable the system to be used in other similar areas (sensors, communication, etc.).
3. DESIGN PROCESS USING C S P - T S S Now we will try to give an overview of global steps in completion of a project task, using CSP-TSS. The first step is to gather all the relevant data about the object, its environment, climate, ground type, and quality and the basic requirements on TSS being designed. This is the preparation step, and it does not involve direct CSPTSS use. The CSP-TSS session starts with the module for the TSS design aid (Section 2.1.). First, the elements of TSS are chosen and connected (supposedly with alternatives) in interaction with the knowledge base (Section 2.1.1.), and then the components are defined using the products database (Section 2.1.2.). After the system is preliminarily designed, the simulation is performed (Section 2.2.) in order to test the functionality of the TSS and gain statistical information (if these are not presented by the producer) needed in the next step. The results of the simulation are passed to the reliability estimation module (Section 2.3.) where we look for a confirmation of the TSS features. The unsatisfactory results can cause a loop to the design step or to the simulation step, using alternative set of components. After the system is "fine tuned" in the last three steps, the module for documentation creation is used (Section 2.4.) as a final step in the design process. The education module (Section 2.5.) can be used to train the future operators of the TSS. 4. C O N C L U S I O N The described implementation of a CAD software package for technical security systems (CSP-TSS) has been an experience in two ways: first, it was the first use o f the DIPSY-E tool in area of design problems; second, it was a large project in creating the complete CSP-TSS. Functional requirements of the CSP-TSS
determined the necessary hardware components, as well as corresponding software. Computer configuration is based on the microprocessor M68020 also containing T E K high resolution graphic terminal along with the mouse and tablet. The software environment needed for CSP-TSS is a U N I X operating system, a compiler for programming language C and Pascal, and the ES development tool DIPSY-E. The choice of programming languages C and Pascal for realization of CSP-TSS is based on the fact that those languages are fairly c o m m o n l y used on microcomputers. This provides, to a certain level, portability of realized software to other computer configurations. For the results, it is sufficient to mention that the complete CSPoTSS is in operation, and the users are evidently generally satisfied. Yet, together with the results, limitations arise. Most important for us was learning the limitations of DIPSY-E as a shell. Some approaches in the user interface of the tool appeared to be inadequate, as well as some language constructions. Thus we have gathered significant and important information on how to improve DIPSY-E (the described system is developed on DIPSY-E V2.x; right now we are working on the V3.x version ).
REFERENCES Barnard, R. (1981 ). Intrusion detection systems. London: Butterworth. Chery, D.D. (1986). Total facility control. London: Butterworth. Filipovi6, A., Kantard~i6, M., & Osmanagie6, S. (1986). Syntactic editor DIPSY-E.Conference Proceedings Computer on University, Cavtat, Yugoslavia. Hahn, S. (1979). Modern electronic security systems. New York. Healy, R. (1983). Design for security. New York: Wiley. Henley, E.J., & Kumamoto, K. (1985). Design for reliability and safety Control. Simp. Series No. 92. PSE 85. Cambridge,England. Kantard~i6, M. (1986). The inference engine in the DIPSY-E development tool for expert systems. Conference on Application of Artificial Intelligence IV. Innsbruck, Austria. Kantard~i6, M., & Kova~vi6, S. (1985). Intelligentform management system. Networks in office automation. North-Holland. Kantard~.i6, M., Glavi6, H., & Filipovi6,A. ( 1988). Computer aided designof technical securitysystems:Approachbasedon knowledge base. Conference Proceedings ETAN'88, Sarajevo,Yugoslavia. Kantard~i6, M., Jeftovi6,M., Glavi6,H., et al. (1990). Expertsystem for technical security systemdesign, lITT Conference "EXPERSYS. ""Grenoble, France. Kantard~i~, M., Jeftovi6, M., Glavi6, H., et al. (1990). A comprehensiveenvironment for computeraid in technicalsecuritysystem design. Proceedings of the International Conference "DEXA '90." City: Springer-Verlag. Kurai, L. (1983). Model for analysis of alarm systems efficiency. Alarm 1-2(2). Morton, H.E. (1984). SENTRAX l--An integrated securitydisplay and control system. 1984 Carnaham Conference on Security Technology, Centacky, Yugoslavia.