Aerospace & Defense Industry Software Directory @ eIT.in

Aerospace & Defense Software @ eIT.in

This section of eIT.in provides web resources for aerospace & defense industry software solutions.

Add Links: If you have a web site that you wish to include in this database, do let us know the details by sending a note about your URL to narsi@esource.in. We’ll quickly review the web site, and if found relevant, add it to the database. We look forward to web site owners and link exchange partners to submit URL. Thanks!

Looking for an outsourcing partner for software development for the aero industry? Have you talked to us?

Other IT Web Sites from eIT.in

Content derived from Wikipedia article on Avionics Software

Avionics software

From Wikipedia, the free encyclopedia

Avionics software is embedded software with legally-mandated safety and reliability concerns used in avionics. The main difference between avionic software and conventional embedded software is that the development process is required by law and is optimized for safety.

Interestingly, some claim that the process described below is only slightly slower and more costly (perhaps 15 percent) than the normal ad-hoc processes used for commercial software. Since most software fails because of mistakes, eliminating the mistakes at the earliest possible step is also a relatively inexpensive, reliable way to produce software. In some projects, however, mistakes in the specifications may not be detected until deployment. At that point, they can be very expensive to fix.

The basic idea of any software development model is that each step of the design process has outputs called deliverables. If the deliverables are tested for correctness and fixed, then normal human mistakes can't easily grow into dangerous or expensive problems. Most manufacturers follow the waterfall model to coordinate the design product, but almost all explicitly permit earlier work to be revised. The result is more often closer to a spiral model.

For an overview of embedded software see embedded system and software development models. The rest of this article assumes familiarity with that information, and discusses differences from commercial embedded systems and commercial development models.

Contents

1 General overview

2 Regulatory issues

3 Development process

3.1 Human interfaces

3.2 Hazard analysis

3.3 Maintenance manual

3.4 Design and specification documents

3.5 Code production and review

3.6 Unit testing

3.7 Integration testing

3.8 Black box and acceptance testing

3.9 Certification

4 See also

5 External links

General overview

Since most avionics manufacturers see software as a way to add value without adding weight, the importance of embedded software in avionic systems is increasing.

Modern commercial aircraft with auto-pilots use flight computers that can fly the aircraft without the pilot's active intervention. Also under development or in production are unmanned vehicles: missiles and drones which can take off, cruise and land without pilot intervention.

In many of these systems failure is unacceptable. The reliability of the software running in airborne vehicles (civil or military) is shown by the fact that most air borne accidents occur due to manual errors.

Regulatory issues

Because of the safety requirements, most nations regulate avionics, or at least adopt standards in use by a group of allies or a customs union. The three regulatory organizations that most affect international aviation development are the U.S, the E.U. and Russia.

In the U.S., avionic and other aircraft components have safety and reliability standards mandated by the Federal Aviation Regulations, Part 25. These standards are enforced by designated engineering representatives of the FAA who are usually paid by a manufacturer and certified by the FAA.

In the European Union the IEC describes recommended (mandatory!) requirements for safety-critical systems, which are usually adopted without change by governments. A safe, reliable piece of avionics has a CE Mark. The regulatory arrangement is remarkably similar to fire safety in the U.S. and Canada. The government certifies testing laboratories, and the laboratories certify both manufactured items and organizations. Essentially, the oversight of the engineering is outsourced from the government and manufacturer to the testing laboratory.

To assure safety and reliability, national regulatory authorities (e.g. the FAA, CAA, or DOD) require software development standards. Some representative standards include MIL-STD-2167 for military systems, or RTCA DO-178B for civil aircraft.

The regulatory requirements for software can be expensive compared to other software, but they are usually the minimum that is required to produce the necessary safety.

Development process

The main difference between avionics software and other embedded systems is that the actual standards are often far more detailed than commercial standards, usually described by documents with hundreds of pages.

Since the process is legally required, most processes have documents or software to trace requirements from numbered paragraphs in the specifications and designs to exact pieces of code, with exact tests for each, and a box on the final certification checklist. This is specifically to prove conformance to the legally mandated standard.

Deviations from a specific project to the processes described here can occur due to usage of alternative methods or low safety level requirements.

Almost all software development standards describe how to perform and improve specifications, designs, coding, and testing (See software development model). However avionics software development standards add some steps to the development for safety and certification:

Human interfaces

Projects with substantial human interfaces are usually prototyped or simulated. The video tape are usually retained, but the prototype retired immediately after testing, because otherwise senior management and customers can believe the system is complete. A major goal is to find human-interface issues that can affect safety and usability.

Hazard analysis

Safety-critical avionics usually have a hazard analysis. Very early in the project, there's usually at least some vague idea of the main parts of the project. An engineer then takes each block of a block diagram and considers the things that could go wrong with that block. Then the severity and probability of the hazards are estimated. The problems then become requirements that feed into the design's specifications.

Projects involving military cryptographic security usually include a security analysis, using methods very like the hazard analysis.

Maintenance manual

As soon as the engineering specification is complete, writing the maintenance manual can start. A maintenance manual is essential to repairs, and of course, if the system can't be fixed, it won't be safe.

There are several levels to most standards. A low-safety product such as an in-flight entertainment unit (a flying TV) may escape with a schematic and procedures for installation and adjustment. A navigation system, autopilot or engine may have thousands of pages of procedures, inspections and rigging instructions. Documents are now (2003) routinely delivered on CD-ROM, in standard formats that include text and pictures.

One of the odder documentation requirements is that most commercial contracts require an assurance that system documentation will be available indefinitely. The normal commercial method of providing this assurance is to form and fund a small foundation or trust. The trust then maintains a mailbox and deposits copies (usually in ultrafiche) in a secure location, such as rented space in a university's library (managed as a special collection), or (more rarely now) buried in a cave or a desert location.

Design and specification documents

These are usually much like those in other software development models. A crucial difference is that requirements are usually traced as described above. In large projects, requirements-traceability is such a large expensive task that it pays for large expensive computer programs to manage it.

Code production and review

The code is written, then reviewed by a programmer that didn't write it (another legal requirement). Skilled organizations also usually review with a checklist of possible mistakes. When a new type of mistake is found it's added to the checklist, and fixed throughout the code.

The code is also often examined by programs that analyze correctness, such as SPARK or lint. The compilers or special checking programs like lint check to see if types of data are compatible with the operations on them. Another set of programs measure software metrics, to look for parts of the code that are likely to have mistakes. All the problems are fixed, or at least understood and double-checked.

Some code, such as digital filters, graphical user interfaces and inertial navigation systems, are so well-understood that software tools have been developed to write the software. In these cases, specifications are developed and reliable software is produced automatically.

Unit testing

Unit test code is written to exercise every instruction of the code at least once to get 100% code coverage. A coverage tool is often used to verify that every instruction is executed, and then the test coverage is documented as well, for legal reasons.

This test is among the most powerful. It forces detailed review of the program logic, and detects most coding, compiler and some design errors. Some organizations write the unit tests before writing the code, using the software design as a module specification. The unit test code is executed, and all the problems are fixed.

Integration testing

As pieces of code become available, they are added to a skeleton of code, and tested in place to make sure each interface works. Usually the built-in-tests of the electronics should be finished first, to begin burn-in and radio emissions tests of the electronics.

Next, the most valuable features of the software are integrated. It is very convenient for the integrators to have a way to run small selected pieces of code, perhaps from a simple menu system.

Some program managers try to arrange this integration process so that after some minimal level of function is achieved, the system becomes deliverable at any following date, with increasing amounts of features as time passes.

Black box and acceptance testing

Meanwhile, the test engineers usually begin assembling a test rig, and releasing preliminary tests for use by the software engineers. At some point, the tests cover all of the functions of the engineering specification. At this point, testing of the entire avionic unit begins. The object of the acceptance testing is to prove that the unit is safe and reliable in operation.

The first test of the software, and one of the most difficult to meet in a tight schedule, is a realistic test of the unit's radio emissions. This usually must be started early in the project to assure that there is time to make any necessary changes to the design of the electronics.

Certification

Each step produces a deliverable, either a document, code, or a test report. When the software passes all of its tests (or enough to be sold safely), these are bound into a certification report, that can literally have thousands of pages. The designated engineering representative, who has been striving for completion, then decides if the result is acceptable. If it is, he signs it, and the avionic software is certified.

At this point, the software is usually very good software by any measurement.

See also

DO-178B

software development model

Hazard analysis

External links

Generic Avionics Software Specification from the Software Engineering Institute (SEI)

DOORs, Software for requirements management (commercial site)

Virtual Avionics Prototyping System Engenuity VAPS avionic HMI design software (commercial site)

Retrieved from http://en.wikipedia.org/wiki/Avionics_software

Categories: Avionics | Embedded systems | Software engineering

End of Wikipedia content, http://en.wikipedia.org/wiki/Avionics_software

Content derived from Wikipedia article on Aircraft Flight Control Systems

Aircraft flight control systems

From Wikipedia, the free encyclopedia

A flight control system consists of the flight control surfaces, the respective cockpit controls, connecting linkage, and necessary operating mechanisms to control aircraft in flight.

The fundamentals of aircraft controls have been explained in aeronautics. Discussion here centers on the underlying mechanisms of the flight controls. Generally the cockpit controls are arranged like this:

Control yoke for roll which moves the ailerons

Control column for pitch which moves the elevators

Rudder pedals for yaw which moves the rudder

Many aircraft use a control stick for both roll and pitch, and the rudder pedals for yaw.

Contents

1 Flight control systems

1.1 Mechanical

1.2 Hydromechanical

1.2.1 Artificial feel devices

1.3 Fly-by-wire

1.3.1 Analog

1.3.2 Digital

1.3.2.1 Aircraft-engine integration

1.3.3 Cars

1.4 Fly-by-optics

1.5 Power-by-wire

1.6 Intelligent

1.7 External links

2 See also

3 Bibliography

Flight control systems

Mechanical

Mechanical flight control systems are the most basic designs. They were used in early aircraft and currently in small aeroplanes where the aerodynamic forces are not excessive. The flight control systems uses a collection of mechanical parts such as rods, cables, pulleys and sometimes chains to transmit the forces of the cockpit controls to the control surfaces. The Cessna Skyhawk is a typical example.

Since an increase in control surface area in bigger and faster aircraft leads to a large increase in the forces needed to move them, complicated mechanical arrangements are used to extract maximum mechanical advantage in order to make the forces required bearable to the pilots. This arrangement is found on bigger or higher performance propeller aircraft such as the Fokker 50.

Some mechanical flight control systems use servo tabs that provide aerodynamic assistance to reduce complexity. Servo tabs are small surfaces hinged to the control surfaces. The mechanisms move these tabs, aerodynamic forces in turn move the control surfaces reducing the amount of mechanical forces needed. This arrangement was used in early piston-engined transport aircraft and in early jet transports such as the mostly mechanical Boeing 707.

Hydromechanical

The complexity and weight of a mechanical flight control systems increases considerably with size and performance of the airplane. Hydraulic power overcomes these limitations. With hydraulic flight control systems aircraft size and performance are limited by economics rather than a pilot's strength.

A hydraulic flight control systems has 2 parts:

The mechanical circuit

The hydraulic circuit

The mechanical circuit links the cockpit controls with the hydraulic circuits. Like the mechanical flight control systems, it is made of rods, cables, pulleys, and sometimes chains.

The hydraulic circuit has hydraulic pumps, pipes, valves and actuators. The actuators are powered by the hydraulic pressure generated by the pumps in the hydraulic circuit. The actuators convert hydraulic pressure into control surface movements. The servo valves control the movement of the actuators.

The pilot's movement of a control causes the mechanical circuit to open the matching servo valves in the hydraulic circuit. The hydraulic circuit powers the actuators which then move the control surfaces.

This arrangement is found in older jet transports and high performance aircraft. Examples include the Antonov An-225 and the Lockheed SR-71.

Artificial feel devices

In mechanical flight control systems, the aerodynamic forces on the control surfaces are transmitted through the mechanisms and can be felt by the pilot. This gives tactile feedback of airspeed and aids flight safety.

Hydromechanical flight control systems lack this feel. The aerodynamic forces are only felt by the actuators. Artificial feel devices are fitted to the mechanical circuit of the hydromechanical flight control systems to simulate this feel. They increase resistance with airspeed and vice-versa. The pilots feel as if they are flying an aircraft with a mechanical flight control systems.

Fly-by-wire

Mechanical and hydraulic flight control systems are heavy and require careful routing of flight control cables through the airplane using systems of pulley and cranks. Both systems often require redundant backup, which further increases weight. Furthermore, both have limited ability to compensate for changing aerodynamic conditions.

By using computers and electrical linkages, designers can save weight and improve reliability. Electronic fly-by-wire systems can respond more flexibly to changing aerodynamic conditions, by tailoring flight control surface movements so that airplane response to control inputs is consistent for all flight conditions. Electronic systems require less maintenance, whereas mechanical and hydraulic systems require lubrication, tension adjustments, leak checks, fluid changes, etc. Furthermore putting circuitry between pilot and aircraft can enhance safety; for example the control system can prevent a stall, or can stop the pilot from overstressing the airframe.

A fly-by-wire system literally replaces physical control of the aircraft with an electrical interface. The pilot's commands are converted to electronic signals, and flight control computers determine how best to move the actuators at each control surface to provide the desired response. Those actuators initially are usually hydraulic, but electric actuators have been investigated.

The main concern with fly-by-wire systems is reliability. While traditional mechanical or hydraulic control systems usually fail gradually, the loss of all flight control computers will immediately render the airplane uncontrollable. For this reason, most fly-by-wire systems incorporated redundant computers and some kind of mechanical or hydraulic backup. This may seem to negate some advantages of fly-by-wire, but the redundant systems can be simpler, lighter, and offer only limited capability since they are for emergency use only.

Analog

The fly-by-wire flight control systems eliminates the complexity, fragility and weight of the mechanical circuit of the hydromechanical flight control systems and replaces it with an electrical circuit. The cockpit controls now operate signal transducers which generate the appropriate commands. The commands are processed by an electronic controller. The autopilot is now part of the electronic controller.

The hydraulic circuits are similar except that mechanical servo valves are replaced with electrically controlled servo valves. The valves are operated by the electronic controller. This is the simplest and earliest configuration, an analog fly-by-wire flight control systems, first fitted to the Avro Vulcan in the 1950s.

In this configuration, the flight control systems must simulate feel. The electronic controller controls electrical feel devices that provide the appropriate feel forces on the manual controls. This is still used in the EMBRAER 170 and EMBRAER 190 and was used in Concorde, the first fly-by-wire airliner.

On more sophisticated versions, analog computers replaced the electronic controller. The cancelled supersonic Canadian fighter, the Avro CF-105 Arrow, was built this way in the 1950s. Analog computers also allowed some customization of flight control characteristics, including relaxed stability. This was exploited by the early versions of F-16, giving it impressive maneuverability.

Digital

A digital fly-by-wire flight control system is similar to its analog counterpart. However, the signal processing is done by digital computers. The pilot literally can fly-via-computer. This increases flexibility as the digital computers can receive input from any aircraft sensor. It also increases stability, because the system is less dependent on the values of critical electrical components in an analog controller.

F-8C Crusader digital fly-by-wire testbed.The Federal Aviation Administration (FAA) of the United States adopted the RTCA/DO-178B, titled Software Considerations in Airborne Systems and Equipment Certification, as the certification standard for aviation software. Any safety-critical component in a digital fly-by-wire system including control laws and the operation system will have to be certified to DO-178B Level A, which is applicable for potentially catastrophic failures.

Nonetheless the top concern for computerized, digital fly-by-wire systems is reliability, even more than analog systems. This is because a computer running software is the only control path between pilot and control surfaces. If the computer software crashes, the pilot cannot control the aircraft. Therefore virtually all fly-by-wire systems are triply or quadruply redundant: they have three or four computers in parallel, and three or four separate wires to each control surface. If one or two computers crash, the others continue working. In addition most early digital fly-by-wire aircraft also had an analog electric, mechanical or hydraulic backup control system.

The computers read positions and forces from the pilot's controls and aircraft sensors. They calculate differential equations that move the flight controls to carry out the intentions of the pilot.

The program in the digital computers let aircraft designers tailor an aircraft's handling characteristics precisely. For example the software can prevent the aircraft from being handled dangerously by preventing pilots from exceeding preset limits (the aircraft's envelope). Software can also be used to filter control inputs to avoid pilot-induced oscillation.

Sidesticks or conventional control yokes can be used to fly such an aircraft. While the side stick offers the advantages of being lighter, mechanically simpler, and unobtrusive, Boeing considered the lack of visual feedback from the side stick a problem, and so uses conventional yokes in the 777 and the upcoming 787.

As the computers continuously fly the aircraft, pilot workload is reduced. It is now possible to fly aircraft with relaxed stability. The primary benefit for military aircraft is more responsive flight performance. Digital flight control systems enabled inherently unstable aircraft such as Lockheed Martin F-117 Nighthawk to fly. A modified NASA F-8C Crusader was the first digital fly-by-wire aircraft, in 1972. The US Space Shuttle (first flown in 1982) has digital fly-by-wire controls. In 1984, the Airbus A320 was the first airliner with digital fly-by-wire controls. In 2005, the Dassault Falcon 7X was the first business jet with fly-by-wire controls.

On military aircraft, fly-by-wire improves combat survivability because it avoids hydraulic failure. A common reason behind the loss of military aircraft in combat is damage causing hydraulic leaks leading to loss of control. Most military aircraft have several completely redundant hydraulic systems, but hydraulic lines are often routed together, and can be damaged together. With a fly-by-wire system, wires can be more flexibly routed, are easier to protect and less susceptible to damage than hydraulic lines.

For airliners, redundancy improves safety, but fly-by-wire also improves economy because the elimination of heavy mechanical items reduces weight.

Boeing and Airbus differ in their FBW philosophies. In Airbus aircraft, the computer always retains ultimate control and will not permit the pilot to fly outside the normal flight envelope. In a Boeing 777, the pilot can override the system, allowing the plane to be flown outside this envelope in emergencies. The pattern started by Airbus A320 has been continued with the Airbus family and the Boeing 777.

Aircraft-engine integration

The advent of FADEC (full authority digital engine control) engines permits operation of the flight control systems and autothrottles for the engines to be fully integrated. On modern military aircraft other systems such as autostabilization, navigation, radar and weapons system are all integrated with the flight control systems.

FADEC allows maximum performance to be extracted from the aircraft without fear of engine misoperation, airplane damage or high pilot workloads.

In the civil field, the integration increases flight safety and economy. The Airbus A320 and its fly-by-wire brethren are protected from low-speed stall. In such conditions, the flight control systems commands the engines to increase thrust without pilot intervention. In economy cruise modes, the flight control systems adjusts the throttles and fuel tank selections more precisely than all but the most skillful pilots. FADEC reduces rudder drag needed to compensate for sideways flight from unbalanced engine thrust. The fuel management controls keep the aircraft's attitude accurately trimmed with fuel weight, rather than draggy aerodynamic trims in the elevators.

Cars

Fly by wire has now become mainstream enough to be used in mass production motor cars. The Toyota Prius Hybrid takes account of pedal action and gear changes to work out how much petrol is required, what CVT gearing to use, and how to apply the electric motor/generator.

Main sections in eIT.in

Outsourcing Support for

Aerospace & Defense Industry Software Directory @ eIT.in

Chat with Narsi

Outsourcing Support For