Embedded aerospace system
An embedded control system is a sophisticated technique to Control the desired section in Aerospace application. It finds its way almost in all sub-systems and min systems including Engine control, Temperature control, Speed control etc. The beauty of the control system model is it takes all inputs from all the Sensors, does all the math to acquire desired gain out of the equation.
How embedded system is working in aerospace:
By “embedded system” we normally (but not necessarily) mean “digital computer system.”
First, it is very important to know about a common misunderstanding of the term “embedded system.” There is the literal meaning, and the typical meaning, of “embedded (computing) system.” The distinction between them has a major impact on the practice of embedded computing, as we will see in this answer, so we need a very brief tutorial.
The literal meaning is exactly what the term says: a computing system that is embedded in an application system. An “embedded” system is essentially an invisible black box that performs some functionality for the application system. The users of the application system might be aware of the embedded computing system, but they have no direct visibility or control of it—as far as they know, the embedded computer’s functionality could theoretically be performed by relays or trained monkeys or even by magic. The users of the application system see and use the human interface provided for them by the application system. The literal meaning is the general case.
Most often, an embedded system’s functionality includes both computation and reaction. Generically, the functionality can be thought of as performing some mix of closed loop and open loop control of devices that are part of or exogenous to the application system. For closed loops, the embedded computer receives data and signals from the application system and the application system’s environment, performs some computations, and outputs data and signals to the application system and the application system’s environment. The operation of open loops follows self-evidently. This is similar to the familiar interaction between a regular desktop or laptop PC and devices inside it (e.g., drives) and external to it (e.g., scanner, camera). Clearly, in some cases, the PC user is involved in some reactive behavior, and in other cases the user is not. However, standalone computers are ordinarily considered as primarily computational or transformational instead of reactive.
It has been asked on Quora how embedded systems relate to real-time systems. My reply is posted elsewhere, but here suffice it to say that “real-time system” is not as “all-or-nothing” or “hard” vs. “soft” as popularly imagined—systems are real-time in various ways and degrees—cf. Many application systems include functionality and devices that are considered to be real-time in the usual sense that correctness requires satisfaction of constraints on the timeliness and predictability of the application and hence on the reactive interactions by the embedded system. Other application systems with embedded systems have the different objective of maximal performance (e.g., throughput, non-starvation).
A major distinction between an embedded system and a non-embedded one is that the developers of embedded systems hardware and software usually need (potentially quite a lot of) understanding about the application system functionality and design, and of the devices therein that it is interacting with. Indeed, often that embedded system hardware and software must be co-designed at a low level of detail (ordinarily the application system’s hardware and software are a given), calling for the education and experience of computer engineering as well as of computer science.
All of that having been said, what is the widespread misunderstanding about embedded systems? It is what was not said.
The typical meaning of “embedded system” is a special case of the literal meaning. It adds a lot of explicit and even implicit assumptions—about the embedded computer, and about the application system, and about the application system’s devices. Most notably, the use of the term “embedded system” almost always incorrectly assumes that the embedded computer is very small scale in size/weight/power, that the embedded computer software is small size, and that the application system is also relatively small scale and simple. Those assumptions are often correct, and everyone can immediately think of many examples.
(As a partial digression: it can be (and is) argued that a smartphone is an application system that has an embedded system—and conversely, that it is not but instead a handheld computer like a desktop or laptop PC. I leave that as a Quorum discussion if it has not already been adequately covered.)
The typical meaning of “embedded system” overlooks the fact that they may be, and are, not just only small scale, but of various scales in capabilities and size/weight/power consumption—all the way up to real-time supercomputers and distributed real-time systems having nodes of various complexities. They are embedded in application systems of various scales, including very large complex ones—e.g., aircraft carriers, military jumbo jets. Such application systems almost always include multiple embedded systems of different scales. Most embedded system developers have not been exposed to, or even heard of, large complex real-time embedded systems and application systems.
That background was needed for me to give my answer to the question, because my experience and expertise in embedded systems is mostly in the literal sense, especially including large, complex, dynamic real-time ones. Those are primarily for military application systems, which are the most wickedly challenging ones due to being engaged in combat and to the “fog of war.” In addition, such systems are unlikely to be mentioned in other replies (which will use the typical meaning of embedded system) to the question.
A real but simplified example from personal experience is modern AESA multi-mission multimode radars on large surveillance airplanes and large warships. Such radars can be expected to have embedded multiprocessor/multicore computers in the multi-million US$ price range, running multi-million lines of software to control the radar and perform the kill chain (tracking, engagement, etc.), and consume vast amounts of power. The radar (on-board and ground-based) users certainly know there is an embedded computer in their radar system, but they do not directly see or control it—they see the application system (radar) user interfaces.
Another example I am very knowledgeable about is application systems for the cruise and ballistic missile defense. Some of these have real-time embedded systems that are supercomputers, that the users do not directly interface with.
You probably will be surprised to hear that some of the companies that make large-scale real-time embedded computers are familiar only in the non-real-time non-embedded contexts (e.g., HP, IBM). Probably you have not heard of most others (e.g., Mercury).
Embedded Systems in Aerospace and Defence Applications :
Aerospace and defence has always been at the forefront of technological excellence and many spin-off technologies have resulted. In fact over $5.2bn worth over the years. Structures, engines, mechanics and all have a vital role to play in these great industries. However arguably its electronics that makes the magic happen. Technology has moved at a Phenomenal pace over the last 20 years Especially in A&D. think Civil Aircraft Inflight entertainment systems. Audio Visual on Demand (AVOD) is now commonplace on long-haul airline fleets around the Globe with touch screens. Even aircraft lavatories are becoming automated with touchless flush buttons. As for the military we will never truly know or understand the level of detail that embedded systems are present in these complex systems so we have to look at what the market currently offers. Still after 20 years Of service PCMCIA, ATA Flash And SRAM cards, which are legacy memory Tech ,are still in operation with plethora airlines. Why? They have far fewer components, are robust and Draw little power. A the time these cards for the only ones available on the market suited to the aircrafts requirements, be it Flight Data recorders, flight deck or avionics. 10 years ago there were around 50 Manufacturers For these cards, today There are are less than 5 as there is a shrinking market. Or is there? Until Aircraft and helicopters are retired or scrapped airline fleets And helicopter operators upgrade to newer aircraft there will still be a demand for these cards. Upgrading flight decks in fixed and rotary wing aircraft is a costly and time consuming job. The more the aircraft is on the ground the less it is earning and with margins tight especially for Airlines they can ill afford to be unnecessarily grounded. Its only recently we heard that the American B52 bomber will continue flying. That will be nearly 100 years of service which seems incredible but it comes down to the points made earlier. Structure engines, mechanical and electrics all will have had to go through strategic upgrades and maintenance at some point. Looking at even Older technology 3.5” floppy disks in particular there is still a healthy demand but getting hold Of them is a different matter. Why are these still around? They don’t break, they work every time and there is a minuscule change of cyber-Attack as the memory is not sufficient enough to host a bug. And for that reason the US Air Force still use these for their nuclear missile silos. Tried and tested works. On the other end of the scale And turning our attention to the latest technology we seeing some Incredible advancements in NAND Flash which if according to Manufacturers and early reports, Will be the staple of memory for years to come. But what about capacity? Only 11 years ago we saw 128MB micro SD cards, now 128GB is the norm.
Embedded application in the military :
A new generation of experts in the embedded computing industry is making yet another attempt to craft industry standards to reduce costs and ease upgrades and life cycle support of military embedded systems.
The HOST program seeks to decompose military embedded systems into functional blocks to ease system design and reuse of embedded computing hardware and software. It’s intended to open systems for several different vendors and avoid locking single vendors into large system designs, Collier told ETT attendees.
The SOSA project, meanwhile, focuses on single-board computers and how they can be integrated into sensor platforms, Collier says. It involves a standardized approach to how embedded systems interrogate sensor data to distill actionable information.
The HOST and SOSA projects are relatively new, yet Navy leaders are starting to push HOST standards on Navy programs, as well as on Navy vendors, Collier says.
Creating embedded computing architecture standards and encouraging industry to use them is a commendable endeavor. It does hold the promise of reducing complexity, cutting system costs, and easing systems upgrades and life cycle support over the long term.
Historically, however, a big problem with military-imposed design standards has been enforcement. The military talks about the need for cutting costs through standard design approaches, yet military program managers want unique capabilities, while military suppliers want value-added designs. A commodity approach rarely achieves these ends.
Military design standards, moreover, have been tried time and again, going back decades to Navy efforts in the early 1990s involving the Next-Generation Computer Resources Program (NGCR), the Army’s Standard Army Vetronics Architecture (SAVA), and the Air Force’s Joint Integrated Avionics Working Group (JIAWG).
Don’t feel bad if you’ve never heard of these initiatives. They were sort-lived, and had little long-term influence on military systems designs. Technology and industry-backed standards overtook them and quickly made them irrelevant. Today essentially they’re forgotten.
The speed of technology presents a formidable challenge to the creation of military and industry design standards. People often criticize how the long duration of military program development often fields obsolete technologies. Standards authorities have to be wary of the same thing: what good is it to standardize on obsolete technology?
It’s easy to be cynical about continuing generations of military electronic design standards. Might the HOST and SOSA projects go anywhere? Says Collier himself, “only time will tell.”
If we choose to be optimistic, then perhaps the HOST and SOSA projects will have some influence. “There are design intersections where working together will work,” Collier says, and I can’t disagree. Most likely these programs on their own will have little influence, but perhaps their legacies will help evolve industry attitudes toward working together as a military establishment and its supplier base.
“People want to work together to make technology stronger for everyone,” Collier says. History has shown that companies will work together only so far as competition will allow. People can voice support for standards, but ultimately each company wants to win the contract, sell the most boards, and promote the best solutions.
We have to consider if competition, not collaboration, is actually what creates the best technologies. Maybe this true, but it comes at a price. Competition generally bubbles the best solutions to the top, but it’s expensive. U.S. military technology can be the best in the world, but it costs hundreds of billions of dollars every year. Is that sustainable in the long term? Probably not in today’s environment.
So that brings us back to cooperation and industry standards. Is this the full answer? Probably not, but maybe it’s a start. There’s a chance that the culture of the military and the embedded computing industry could be changing, albeit slowly.
When it comes to industry associations and standards bodies, “there is more participation than I’ve ever seen before,” says Jerry Gipper, executive director of the VITA Open Standards and Open Markets embedded industry trade group, which puts the ETT conference together.
“Technology changes, and so do business models,” Gipper says. “It may just work this time. I do think we are going in the right direction.”
Of course, there are different grades and specifications of memory and storage, the Commercial of the Shelf (COTS) that you can buy in any good high street or web store to the premium end of the market – the industrial grade. IT is here the aerospace and defence industries where industrial grade memory and storage sits. There is a requirement to store large amounts of data; securely, in harsh temperature environments ranging from -40°C to 85°C often for long periods of time. The difference is often underneath the casing (although rugged metal casing is not uncommon) and the difference can vary dramatically depending on the manufacturer. Power protection, SMART Monitoring, AES 256 bit encryption, conformal coating, hardware and firmware alterations and more importantly NAND FLASH all vary differently as do the Capacities Of Storage devices. The holy grail of achieving 1TB storage in an industrial grade SSD has been achieved by many who are now starting to push the boundaries even further by introducing 2TB and in some cases 4TB. Interestingly a Korean company, Novachips is Slowly introducing an 8TB SSD which is Primarily for the military market. Early indications from a selection of clients show that the SSD has ‘groundbreaking performance’. So just how good is it? For the military Key Characteristics of any type of storage technology should have;
- 2.5”7mm height
- MIL-STD-810F/G compliant
- Military Secure Erase protocol supported
- 256-BIT AES Encryption, Secure Erase and Write protect supported
- Adaptive thermal control
- Fixed BOM (Controller, NAND, and Firmware)
- Constant write performance.
- On-board Capacitor Sudden Power off Protection,
- End-to-End data protection
- An ultra-rugged robust metal casing
- Wide operating temperature-40°C to 85°C