In developing the Prolog program, the first step was to describe a set of rules for the program to fulfil. During development, questions to these rules come up, and more rules may become necessary. Therefore the set of rules are not to be considered a static entity. The set will evolve in a number of iterations during the development of the program.
Some of the rules are expressed in such a way that they can be more or less directly translated into Prolog predicates. Other rules have a more subtle formu-lation, which makes them more difficult to implement. The rule ”The jammer will reveal the position of the aircraft” is an example of one such rule. While it is true, and relatively easy to implement, the implications of the rule on the Prolog program are not obvious. A rule stating ”The jammer should only be active in a non-severe environment if it mitigates a missile launched towards the aircraft”, would describe the same intention: the jammer should not be active unless it makes a positive difference to the survivability. Implementing it in the program is just as easy.
4.7 Discussion 67
Running a Prolog program, compared to running a program written in e.g. C or C++, will often require substantially longer execution time. One reason for this is that when the execution of a program finds an answer to a goal, this answer is not stored, and the next time the same goal is set, the answer will be obtained once again. Another reason is that the Prolog program is often interpreted, which itself is almost synonymous with a prolonged execution time.
There exist Prolog methods for self-modification, so that answers to goals that may be used multiple times, are stored as facts. For the program developed here, running on the laptop PC described in Appendix E, the execution time never exceeded 150 ms. To this amount of time the time it takes to process data before and after the PrologDSSis invoked needs to be added. Processing data constitutes collecting relevant sensor output data from systems on-board the aircraft and preparing them for processing by the DSS, and after a list of relevant actions is found by theDSS, the list must be prioritized and presented to the pilot. Although the total amount of time is not known, it is assumed that for most scenarios it will be less than the 200 ms limit set in Section 3.3.
Therefore no measures are taken to improve execution time in this work.
In using this program, an approaching missile can be ”hidden” by a friendly aircraft. Even if theMWSrecognizes the missile the MWSwarning will be con-sidered false if it is placed in an angle similar to that of a friendly aircraft.
While this will bring down the number of false alarms, it can not be described as failsafe. If a missile is in fact attacking from this angle, only the aircraft closest to the missile will respond to it. This might be enough to mitigate the approaching missile; but combining the effort of more aircraft could increase the effect on the missile, thus providing all friendly aircraft with a higher survivabil-ity. If warnings from the MWSwere to be shared among the friendly aircrafts, using e.g. a data link system, this could add to the usability of the DSS. A
MWSwarning repeated by a friendly aircraft in the same direction may not be ignored and proper evasive actions have to be found.
The order of the declarations of predicates, as well as the order of predicates within other predicates, will have no influence on the results given by the in-terpreter when a program is interpreted according to the definitions of Prolog.
B-Prolog, as well as most other Prolog interpreters, does not comply with this in full. An example of this can be seen in Figures 4.6 and 4.7.
recommend_cm(_,(Angle,_),Cm) :-approp_list(Angle, Cms), memberof(Cm, Cms).
Figure 4.6: Implementation of recommend cmthat works.
68 The Prolog Approach
recommend_cm(_,(Angle,_),Cm) :-memberof(Cm, Cms),
approp_list(Angle, Cms).
Figure 4.7: Implementation of recommend cmthat does not work.
When a Prolog program is interpreted, the predicates are tested in the order they appear. In the working version of therecommend cm predicate, shown in Figures 4.6, the approp list is interpreted first, thus instantiating the list of appropriate countermeasures,Cms, which is then used in the second predicate.
In the non-working version, shown in 4.7, the order of these two predicates is reversed. Hence the interpreter will first try to make a list containing the variable Cm. Since Cmis not instantiated, there exists no defined list that will fulfil this clause, and the query will not succeed. Whether the Prolog interpreter implementation discovers this, and exits gracefully, or keeps on running until it is out of memory, is entirely up to the implementation. The B-Prolog interpreter does not detect this inexpediency, an continues to look for the countermeasure until it runs out of memory.
Some facts are meant to occur no more than once in the Prolog program. For instance declaring multiple instances of the altitude or the fly mode makes no sense. Despite of this, it can easily be done, resulting in a program that does not behave according to the intentions. Declaring morealtitudes could result in the position of the aircraft being interpreted as out of range of bothIRand
RF guided missiles. To solve this kind of conflicts the directive oncemay be used. Replacingaltitude(Alt)withonce(altitude(Alt))will result in only the first instance of altitudebeing used.
In Section 4.1 it is stated that Prolog programs are easy to read. While this is true, the readability can be enhanced introducing e.g. operator descriptions.
Mathematical operators, such as + (add), - (subtract), / (divide),·(multiply), or % (percent) are easily recognized. They can be either prefix, (+ and -), infix (+, -, /, or ·), or postfix (%), and they are described by a precedence. The precedence is used to establish the order in which operators are evaluated, star-ing with the lowest precedence, and since division and multiplication have lower precedence than addition and subtraction, the expressionA + B / C − D · E is equivalent toA+ (B/C)−(D·E).
The operatoris guided bycan be declared by giving the directive:-op(600, xfx, is guided by). It is given the precedence 600 and thexfxpart describes it as an infix operator. Operators may be prefix (fx), infix (xfx), or postfix (xf). With theis guided byoperator the factguidance(sa2, command)may be written as sa2 is guided by command, which may be closer to a natural