Conventional automation is the employment of automated functions in work systems we are used to so far. Many people think it is the only way to automate. One fundamental characteristic of conventional automation is the fact that it is focused on functions of execution as part of the operation-supporting means. Regarding vehicle guidance and control work systems, for instance, one would think in this context of autopilot and flight management systems for the cockpit work site of pilots or of cruise control and the anti-lock braking system (ABS) in our cars. These automated execution functions include at one end subtask functions like those, for instance, to alleviate the operator's access to important information (automation of information acquisition and display.. At the other end, execution functions for system control (automation of system control) and higher prefixed functions for problem solving and planning tasks like those of the flight management system and the navigation system in our cars (automation of system management) are included. In addition, if we consider the cognitive elements of a conventionally automated function, the following characteristic has to be accounted for, too: Conventional automation is never driven by any own explicit or implicit motivational contexts.
There are no own initiatives subject to own motivational contexts to change the current task in case of any unforeseen situational interference. This is exclusively left to the human part. Therefore, only the motivational contexts of the human operator and the work system designer are the driving mechanisms to operate the work system. The designer, based on his/her motivational contexts, tries to imagine the motivational contexts of the human operator while operating the work system subject to the work objective. Having this in mind the designer tries to envision the associated task situations, to figure out the tasks to be automated, and possibly to envision goals to be associated to an automated planning function, if this would have to be designed, too. That means: all situational options have to be considered in that design process. Obviously, this is not an easy job if not an impossible one. The more complex the work process is the more it becomes uncertain in a particular situation that the automated functions are being in sufficient compliance with the motivational contexts of the human operator. The crucial fact is that the automated function cannot verify on its own here and now in the course of the work process, whether it really acts in compliance with the motivational contexts of the human operator. One has to live with the fact that mismatches might occur and might have fatal consequences in extreme cases.
A very simple example might illustrate this. If a pilot activates the autopilot for the subtask "altitude hold", the system is doing its best to comply with the assigned altitude, even if a high mountain might be in the way. The prime goal to warrant safety in this case which the pilot has in his mind as motivational context, i.e. to explicitly avoid a crash into the mountain, is not known by the autopilot. Therefore, it does not care. Here, the deficiency of the conventionally automated autopilot function of only complying with a task command of holding an assigned altitude and not accounting for any more possible superiror goals makes the work system vulnerable to human errors in the course of the work process. Admittedly, it is hard to believe that the pilot does not notice the threat of the mountain popping up, at least if flying under VMC (Visual Meteorological Conditions). But think of the accident of the American Airlines flight 965 from Miami to Cali (Columbia) in 1995 which happened in poor visibility conditions. Being inbound to Cali about 35 miles from the destination on a southerly heading the air traffic controller offered a straight in approach with a much shorter distance to touchdown than planned. The crew accepted this clearance, although the airplane was too high and too fast. Immediately, there was a high workload on the crew to keep everything under control. Power was reduced and speed brakes extended to acieve a high descent rate. Approach charts had to be changed and the flight management system (FMS) had to be reprogrammed. When the controller cleared the Boeing 757 to fly directly to Rozo which is a radio beacon close to the runway, the copilot keyed into the FMS its identifier "R" as being looked up from the map and executed the entry right away. The plausibility of the entry was not checked, though, due to high workload. Now, being under automatic control by means of the FMS the airplane was immediately leaving the course for the straight in approach and made a left turn towards a mountainous area, still with a high descent rate. The crew did not notice this considerable change of the flight path until the aircraft had turned up to about 900. Even sharply turning back the plane towards the approach centreline when noticing the wrong heading, could not prevent the accident.
The airplane crashed into a mountain about 20 miles short of its destination. This controlled flight into terrain (CFIT) mainly happened because the crew was kept up with too many activities to manage the landing approach. Therefore, they did not sufficiently abide to the standard operating procedures (SOPs) to pay attention to important cues for situation awareness, apparently not knowing of the ambuigity problem when entering the identifier "R". In fact, "R" is the correct code for Rozo as far as the approach chart is concerned; but the FMS database was programmed according to the ARINC standard. This makes a terrible difference, because in this very specific case the identifier "R" in truth stands for a so-called Romeo beacon close to Bogota just not too far away.
Typically, the FMS, although a rather complex operationsupporting means of conventional automation for flight planning and execution has no idea about what the motivational contexts of the piloting crew really were. It could not do anything to avoid the accident. It lacked the necessary cognitive capabilities which were exclusively reserved to the human crew. This example illustrates that we have not named conventional automation that way in order to delineate between past and future developments of automation only, although this is probably the case to a very high degree. We rather intend thereby to mark the principle difference in design philosophy when talking about conventional automation in distinction to what we shall describe later on under cognitive automation. We have to account for two different ways of introducing automation into the work system design. On the one hand, there is the concept of operator-controlled automation which can be considered as what is known under supervisory control in a wider sense. In this case, the automated function is activated, monitored, and turned off by the operator in the course of the work process. By experiencing the behaviour of the automated function the operator forms a model of its behaviour and is using it correspondingly subject to his/her motivational contexts. On the other hand, there are automated functions which are to be dealt with as an intrinsic part of the vehicle or other components of the operationsupporting means, not leaving an option for the operator of turning off these functions or directly controlling them. The operator might even be totally unaware of the fact that there exists an automated function of that kind in the system.
At one end, for example, the main part of information displays we are used to in vehicles and the means to derive the information presented belong to that category. At the other end the ABS in our car is also a typical example. In the following, we shall call this concept built-in automation. It is entirely up to the work system designer to decide whether a function of that kind is to be implemented as well as when and how it is to be activated in the course of the work process. Therefore, the design of conventionally automated functions of this kind has to be even more careful. Automation in work systems has usually been started by introducing built-in automation. Built-in automation and operator-controlled automation often are present in work systems working in parallel. In the following, the main focus will be on operator-controlled automation (supervisory control).
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Norris Sutton at 01152010
1. Automatic systems for guidance and control in automotive vehicles
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.