Speaking of pain -1999- Поговорим о боли
I want you to excuse my uneducated and primitively-materialistic description of the pain mechanism. The extremely complex structure of our biological machine, among numerous other things, contains an elaborate system of gigantic number of sensors, distributed all over our body. These sensors can generate special signals that we perceive as pain. Let us be realistic about the nature of pain: pain is an automatically generated alarm indicating that something is wrong in our body. It is a warning message indicating an incipient failure. While the location of the pain and its character contain some diagnostic information, we view our pain primarily as it is intended: as a “request for service” generated by our body that, in turn, may result in the diagnosis, and more direct intervention, a “repair”. It looks like it is unfair that our body automatically detects failures in its different subsystems but, generally, does not identify them. The explanation is quite obvious: human beings have been experiencing pain for at least fifty thousand years, but the access to the blueprints of our biological machine, created by God, we got only recently. Any diagnostic information provided prior to this advancement would be meaningless and all “repair” efforts most likely would cause more harm than good.
Let me summarize my layman’s excursion to human biology. The high reliability of our biological machine has been assured by a distributed monitoring system capable of incipient failure detection and generating warning messages in the form of pain. Combined with recent advancements in medicine, the pain mechanism has resulted in a full-scale diagnostic system performing failure detection, identification, and prediction, thus facilitating “condition-based maintenance” as well as “preventive maintenance”.
I would take the liberty to claim that amoebas do not have a distributed pain-generating sensing system because of their relative simplicity. Because of the same reason, the Wright brothers did not install a distributed monitoring system on their airplane. Trees do not have a pain mechanism because they just cannot do anything about requesting maintenance. My dogs do have pain mechanisms, and their requests for maintenance (primarily food) made me unpopular among my neighbors. The airliner that recently fell out of the sky into the ocean, bringing its passengers and crew to an untimely death, did not have a pain mechanism and did not feel pain in its flight actuator with a badly worn drive screw…
We are building technical systems of tremendous complexity and cost. Reliable operation of these systems is critical for the safety and wellbeing of millions of people. Technically, we are prepared to provide “pain mechanisms” to our most valuable creations in the form of automatic monitoring systems capable of automatic detection of incipient failures. We have very advanced micro-sensing technology. We have access to miniature microprocessors capable of distributed real-time data acquisition and signal processing. We use “smart” materials with built-in sensors and microprocessors. Therefore, our complex technical systems must feel pain and report it to us before it becomes our pain. These cries for help, along with the recorded and uploaded information, should initialize failure detection, location, identification and prediction procedures, as well as requests for maintenance. Yes, we can play God with our technical systems: we do have their exact blueprints! Yes, we do have the required hardware for computer-based on-line system diagnostics. Yes, we do have the necessary mathematical procedures and hardware, see for example, my humble attempt in this area [1].
What could be done about this worn drive screw of the flight actuator that brought aircraft to the bottom of the ocean and became famous enough to be shown on national TV? My analysis of this screw is as follows:
1 – the damage was not made by fish when the actuator was on the ocean floor
2 – the damage, as shown on TV, resulted from gradual wear of mechanical components of the actuator and/or control surface
3 – the damage could be detected in a timely fashion without disassembling the actuator.
Let us try to understand what was happening inside the actuator. Let us visualize the sequence of electro-mechanical transformations within the actuator. Each time the reference signal R changes, or the control surface is deflected by wind, the entire system undergoes a transient process that results in equilibrium when the angular position of the control surface, P, is equal to the reference (I happen to be a control systems professor).
I can recommend to anybody, who has access to a simulation software tool (SIMULINK or VISSIM) and some clue for the order of magnitudes of system parameters, to assemble and run the simulation model of a flight actuator and its control system. The results of a number of simulation experiments should be summarized as an empirical curve relating the motor current to the acceleration of the surface position, reflecting the operation of a brand-new actuator. As soon as this relationship will be established, a small change in the friction and/or stiffness parameters of the above system, should be made. Why friction and stiffness? – because they represent mechanical deterioration of moving parts of the actuator and/or the control surface. Then simulation experiments should be conducted on the perturbed model. The result is easy to predict: the “real” acceleration/current points will noticeably deviate from the previously established “normal performance model”. Real acceleration/current measurements, even affected by noise, could be continuously obtained on a “real” system during its operation. One may expect that their deviation from the “nominal curve” exhibits a trend. This trend, validated by statistical significance analysis, would provide a clear evidence of gradual changes in the mechanical structure that always represent only one thing: structural deterioration. Therefore, simultaneous monitoring of two actuator parameters, with proper analysis, could provide meaningful diagnostic information at very early stages of the developing failure: long before the tragedy occurred. The aircraft could and should “feel a pain in its actuator” and its “cry for help” could and should be heard.
1. V. Skormin, J. Apone, J. Dunphy, “On-Line Diagnostics of a Flight Control Actuator”, IEEE Transactions on Aerospace and Electronic Systems, June, 1994
This paper was published in the IEEE Aerospace and Electronic Systems Magazine, June 1999, V.14, N6, p.10
Свидетельство о публикации №223033100224