Basic Computers — Page 315, Lesson 371

Let's start with programming languages, because that's where this chapter opens. I want to walk you through the distinction between a high level language and a scripting language, because they're both software concepts, but they serve very different roles. A high level language is an advanced computer programming language that is not limited by the computer, or for one specific job, and is more easily understood by the author than an assembly language. Let me unpack that. "Not limited by the computer" means the same program can run on different types of hardware. "Not for one specific job" means it's general purpose. And "more easily understood by the author than an assembly language" — assembly language is the low-level code that talks almost directly to the processor, which is very hard for a human to read. A high level language sits above that, closer to human thinking. Examples given are FORTRAN, ALGOL, BASIC, and C++. Those are the classic high level languages. Now a scripting language is different. It's a programming language that allows control of one or more applications. The key idea is that "scripts" are distinct from the core code of the application, and they apply to a specific program only. So the core code is the main program, and a script is a separate set of instructions that drives that program. Scripts are usually written in a different language, similar to Basic, and they are often created or at least modified by the end-user. So the end user can tweak how the application behaves without rewriting the whole program. Now, here's where it gets serious for aviation. There's a specification for software used in aircraft. To enable a flight to be conducted safely, it is vital that any computer software must be safe to use and free of any errors that could endanger the flight. So a specification has been agreed to which all aircraft related software must comply. That specification is known as EUROCAE ED12B. EUROCAE is the European Organisation for Civil Aviation Equipment, and ED12B is the document number. There are 5 levels of software defined, and the level required will depend upon the application. The example given is perfect: the galley oven controller could accept a major failure without endangering the aircraft, whereas any failure within the Flight Control Computer could be dangerous to the flight. So the more safety-critical the function, the higher the software level required. This is captured in a table called Safety Criticality (EUROCAE-ED12B). Let me walk you through all five levels, because you need these exactly. Level A corresponds to a Catastrophic failure condition. The interpretation in the aviation context is: prevent continued safe flight or landing. So if this software fails, the aircraft cannot keep flying safely or land. That's the most severe. Level B is Hazardous/Severe-Major. The interpretation: potential fatal injuries to a small number of occupants. So a failure here could kill some people, but not necessarily bring the whole aircraft down. Level C is Major. Interpretation: impairs crew efficiency, discomfort or possible injury to occupants. So the crew can't work as well, people might get hurt, but it's not fatal on a large scale. Level D is Minor. Interpretation: reduced aircraft safety margins but well within crew capabilities. So the safety margin shrinks, but the crew can still handle it. Level E is No Effect. Interpretation: does not affect the safety of the aircraft at all. That's the galley oven territory. Now let's look at the aircraft systems that are computer controlled. The list includes the Flight Management System (FMS), the Digital Flight Guidance System (DFGS), the Ground Proximity Warning System (GPWS), and the Traffic Alert Collision Avoidance System (TCAS). And of course, fly-by-wire aircraft take computer control very much further — the whole flight envelope is controlled by computer process, with inputs from the crew when necessary. So on a fly-by-wire aircraft, the computers aren't just monitoring; they're actively flying the aircraft within its limits. Current design favours the use of dedicated computers for each separate system. So each system — FMS, GPWS, TCAS — gets its own computer. But in the future, we may see sharing of computer power in the form of an Integrated Hazard Warning System (IHWS). Here, a powerful central processor, with appropriate back-up, handles inputs from the stall warning system, windshear detection, GPWS, TCAS, and even the Weather Radar. It processes the information and prioritizes warnings to the crew. So instead of five separate boxes each beeping at you, one central brain takes all the hazard inputs, decides which warning matters most, and presents that to the crew first. Finally, we need to talk about how computers talk to the real world. Many aircraft sensors produce analogue information — that's information in the form of varying voltages, pressures, temperatures, and so on. But digital computers use digital (binary) information — ones and zeros. So a device called an Analogue to Digital Converter is required in the interface between the sensor and the computer input device. That's the A to D conversion — it takes the continuous analogue signal and turns it into discrete binary numbers the computer can process. And the reverse: when a digital computer has to pass information to an analogue device, the process is reversed, and a Digital to Analogue Converter is used. That's the D to A conversion — taking the binary output and turning it back into a continuous signal, say to drive a needle on a gauge. So the whole picture is: sensors produce analogue signals, an A to D converter digitizes them for the computer, the computer processes using software certified to EUROCAE ED12B at the appropriate level, and if it needs to drive an analogue device, a D to A converter translates back. That's the complete loop.