Aerospace & Defense

The Advent of Multi-core MILS

By Paul Parkinson

It has been a rather long time since my previous blog post. I intended to post a blog before the holidays regarding our partner Curtiss-Wright's announcement about VxWorks MILS support on the VPX6-187, but I simply ran out of time! So here it is as my first blog post of 2013.

The Curtiss-Wright new release was actually quite a game changer. To the casual reader, it may just appear to be about the release of another board support package (BSP) on a leading-edge COTS processor card, but the fact that this BSP supports multi-core for a MILS architecture is what makes this announcement so significant.

When the MILS software architecture was proposed in 1984 by the computer scientist Dr. John Rushby, microprocessors at the time were inherently single-core, and computing performance advances were being driven by clock speed increases and die size, at a rate following Moore's Law.

Over the last decade, single-core processors with robust MMU partitioning have become sufficiently performant to enable viable MILS separation kernels (SK). In recent years, Wind River has implemented VxWorks MILS on single-core processor architectures (PowerPC MPC8548), and on multi-core processors, but only running on a single core (dual-core PowerPC MPC8641D, quad-core Intel Core i7).

However, with the VxWorks MILS Platform, Multicore Edition, the VxWorks MILS separation kernel now runs on all eight cores of the Freescale QoriQ P4080 processor concurrently. Yes that's right, I am talking about (MILS & multi-core) rather than (MILS XOR multi-core). This enables the integration of many MILS solutions on a single processor, creating reduced size, weight and power (SWaP) benefits - even high assurance security-critical systems have tough performance requirements.

The advent of multi-core processor architectures over the last few years has had a dramatic and disruptive effect on the embedded market. This has provided significant benefits in terms of reducing size, weight and power (SWaP), but has also presented some interesting challenges for safe and secure application domains.

For example, the global aerospace market has very mature processes for DO-178B safety-certification on single core processors. Similarly, the security community is approaching maturity for Common Criteria security evaluation on single core processors. But both segments are challenged when driving multicore systems through their respective processes.

There has also been an emerging trend in recent years of individual systems needing to meet both safety-certification and security evaluation, and now with the emergence of multi-core, this presents some new regulatory challenges, but the benefits will be worth the effort.

This convergence is discussed in more detail in the white paper 'Safety, Security and Multicore' which is available for download from the Wind River website.

For additional information from Wind River, visit us on Facebook.

Avionics Europe 2012 Report

By Paul Parkinson

I've just got back from the Avionics Europe 2012 conference and exhibition which was held in Munich.

The theme of this year's conference was 'Common Sky: Operating in One Air Space' focussing on the growth in air traffic across Europe, the challenges arising for air traffic management and navigation, and the development of SESAR air traffic management technologies.

I was keen to hear to how changes to the high-level policies would drive regulatory changes and drive technology requirements.

I didn't have to wait very long, as in his keynote speech, Brigadier General Hans-Georg Schmidt (Vice Commander of 1st German Air Division, and Chairman of the Military Air Traffic Management Board of EUROCONTROL) discussed the implications of the integration of unmanned systems (UAVs, UCAVs) into non-segregated airspace. He discussed the need for unmanned systems to be "sufficiently safe as not to reduce the overal safety of airspace," and said that unmanned systems "must be proven to be safe before their introduction into this environment." (The keynote speech is discussed in more detail by John Keller, conference chairman, in this blog post).

This subject of UAV safety certification was covered in more technical detail by Richard Seitz of Cassidian in his presentation on 'UAV Computing'. He discussed the differences between flight software on piloted aircraft (which leaves the ultimate decision to the pilot) and flight software in unmanned systems which becomes safety-critical in the case of datalink loss,  and the need for RTCA DO-178B / EUROCAE ED-12B safety certification of UAV flight software. 

It was encouraging to see the subject of UAV safety and the need for software certification being acknowledged, as this was a topic which I had also raised in my conference paper  in the context of combined safety and security requirements for unmanned systems (for details see my previous blog).

The other recurring theme at the conference which caught my attention both in the conference and in the exhibition, was the technology disruption of multicore processor architectures, which provides some exciting opportunities for reducing the size, weight and power (SWaP) of avionics systems, but also presents new challenges for hardware and software safety certification. However, there's now significant momentum in the research into these areas, and the experience gained should lead to regulatory guidance and adoption in the near future.

So overall it was an interesting and enjoyable conference, not least for the fine Bavarian hospitality!

Autonomy and Robotic Advancement

By Mike Deliman

A few months ago at the Robotics Virtual Trade Show, in my presentation I spoke about the evolution of robotic systems.  One thing I predicted was as time goes on, robots will become more independent and autonomous, performing more of the work humans and mainframe-style systems have traditionally performed.  

Among the robots I talked about were robots similar to NASA's 
Stardust Spacecraft  Stardust is currently on course for a Valentine's Day rendezvous with Comet Temple-1.  Stardust includes a package that performs autonomous navigation, d to help keep the craft on it's flight path with reduced intrusion from ground-based systems.  Since Stardust is so far out from earth, there is significant delay in round-trip communications.  Stardust is able to detect problems in trajectory and perform course correction maneuvers on its own.

Last week, Northrop Grumman had  first-flight for an evolution in Un-maned Aerial Vehicles.  The 
X47B UCAS   is an autonomous unmanned flight system.  It is not a wireless-joystick system.  It flies itself, taking off, figuring a course to it's way points, landing.  Without human intervention.

This, in general, is the trend of the robotic future.  There will be more "robots" in all sectors, the robots will become more autonomous, and perform more of the work regarding their duties than in the past.

In general a robot is an artificial entity that performs work for humans.  I broaden this definition to include telepresence systems (telerobotic surgeons, astronauts, and systems like aercams on the ISS), and lifestyle assistants (products such as drobo, tivo, and roomba).  My thoughts are that these consumer systems are both cutting edge, and primitive.

They are cutting edge in that they do some pretty incredible things in comparison with competing products that were available at the times these were invented.  They also pushed conventional wisdom about engineering and marketing, and created some cool and popular products.  They are primitive when you consider what technologies are available and how they could be used to upgrade these devices, and how these technologies will evolve over the next 5 years.  If you think about DVR boxes, you can get new DVRs from many makers,  yet used TiVos sell for over $200!  It's because TiVo can use the programming you record to automagically select other programs to record for you.  It anticipates and adapts based on your habits.  This capability differentiates it from other DVRs.  It does more work for you than others do.

This trend of more intelligence and autonomy will eventually blend its way into everything from automotive products to tourism.  It could lead to smarter cars that can detect when the driver's attention is lapsing or alert that it is unsafe to pass due to oncoming traffic.  There may someday be a system of telepresence pods anywhere on earth or even in orbit, where you could schedule a short vacation and experience a different world just by putting on a special helmet and gloves.  With such systems you could control a telerobotic diver and explore a sunken wreck, then change connections and view the Earth and stars from orbit... Possibly even while driving home from work. 

Such systems require many things to make real, among them is vision and technology.  With the proper technology your vision may be wrought into reality.  WindRiver is proud to be involved with programs like NASA/JPL's Stardust and Northrop Grumman's X47 UCAS.  Congratulations to X47B on successful first flight, and Stardust's upcoming Valentine's day rendezvous.

Safety-Critical Systems Symposium 2011

By Paul Parkinson

I'm looking forward to the 19th annual Safety-Critical Systems Symposium which is being held in held in the UK next week.

The conference programme covers a range of subjects including safety cases, testing of safety-critical systems, updates to safety standards, and technologies. On the Thursday afternoon, I will be presenting a paper Safety, Security and Multicore.

Wind River will be participating in the exhibition which is being held on the Wednesday, and we will have a live demo of VxWorks MILS 2.0 running on the stand. So why not pop by to discuss your safety & security requirements?

 

IMA on Simics: An Interview with Tennessee Carmel-Veilleux

By Jakob Engblom

After Summer, I have been in contact with Tennessee Carmel-Veilleux at the École de technologie supérieure in Quebec, who has been doing some really cool work with Simics.  Tennessee has learnt Simics very quickly, and has been very clever in how to apply Simics to the research problems he has encountered. In this interview, he tells us some more about his research and use of Simics. I prefix my comments with "JE", and his with "TCV".

JE: We start with the basics. Can you introduce yourself?

TCV: My name is Tennessee Carmel-Veilleux and I am a masters student in the Electrical Engineering department at École de technologie supérieure (ÉTS) in Montréal, Québec. I hold my B.Eng EE from ÉTS as well as an Electronics Design Technician diploma from Collège Maisonneuve.  I am part of the AREXIMAS joint project between ÉTS and Polytechnique. My advisor is Prof. Jean-François Boland and my co-advisor is Prof. Guy Bois from École Polytechnique. I am finishing my Master's remotely from Waterloo, Ontario, where I live with my wife and our son.

JE: What is your university and research group?

TCV: École de technologie supérieure is an engineering school in the University of Québec's public university network. It has the largest undergraduate engineering program in the province of Québec. Admission is restricted to students who have previously completed technical collegiate studies diplomas, although they are now accepting non-technicians through a one-year technical apprenticeship

I belong to the AREXIMAS (ARchitectural EXploration of Integrated Modular Avionics Systems) research project, a joint effort between École Polytechnique de Montréal and ÉTS. We are funded by the CRIAQ, a local aerospace academic research consortium that fosters links between industry and academia. The project currently has three faculty members, three masters students and one PhD student.

During my undergraduate studies I was significantly involved in the SONIA autonomous underwater vehicle (AUV) project. The goal of that project is to build intelligent submarine robots to participate to AUVSI and ONR's internation AUV competition. Since starting my master's, I have been doing technical consulting with the team.

JE: What is your research about?

TCV: My research project is about the use of multicore embedded processors for Integrated Modular Avionics (IMA) applications. IMA is a systems architecture for avionics platforms that consolidates multiple avionics functions on highly-integrated embedded computers. Classical "federated" avionics systems used to have one single computer for every avionic function (such as Flight Management System (FMS), Flight Control System (FCS), actuator controls, cockpit data display systems, etc) [1,2]. Newer aircraft such as the Airbus A380, Boeing 787 and Dassault Falcon 7X all use IMA to reduce the size, weight and power used by their avionics bay.

JE: Multicore and Avionics, sounds like a difficult combination to me?

TCV: Right now, the market is very slowly starting to evaluate multicore technology for avionics applications. On one hand, this is because multicore SoCs are moving so quick that very little reliability and availability history have been established [3]. The complexity of modern SoCs doesn't help with safety and certification concerns. On the other hand, IMA requires the use of robust partitioning, such as that provided by ARINC-653 operating systems [4], to ensure fault containment amongst the multiple separate applications that run on an IMA platform. There are still many open questions about how to certify multicore versions of these for flying [5].

This field has a lot in common with the current interest in hypervisors for running multiple completely separate applications and OSes on embedded systems. Multicore processors offer the enticing prospect of integrating an even higher number of applications in the same physical space as current single-core systems.

This is where my research project comes in: I am adapting an existing academic robust partitioning kernel called XtratuM [6] to work on multicore PowerPC SoCs such as the Freescale MPC86xx, MPC85xx and QorIQ series. The picture below shows an overview of the Xtratum architecture:

The adaptation work we are doing has two objectives:

1. Provide a proof of concept multicore robust partitioning kernel that can be used for research of safety issues mitigation.
2. Highlight implementation safety issues in moving from current single-core IMA systems to multi-core IMA systems.

Some companies are already working on certified multicore avionics operating systems. My research project aims to bring a research-grade platform to other academic users so that work can be done on solving already identified multicore safety problems without resorting to proprietary implementations. Iwant to allow other researchers to try different approaches to maximize IMA integration on a multicore processor while remaining safe. Surely not all ideas have been tried yet.

It is well understood in the IMA community that multicore processors trump all assumptions about computing platforms that underlie current IMA standards and implementations. We sort of need a paradigm shift because what integrators want are higher integration and low development and upgrade costs. These conflicting goals have many possible solutions with multicore/manycore processors, but for sure we need to see beyond the current ideas that try to cast multicore in the mold of a multiplexed single-processor (to follow the structure and strictures of existing standards).

JE: How do you use Simics in your research?

TCV: I used Simics as my main prototyping tool for code development. The Simics MPC8641-simple model (containing a Freescale MPC8641 SoC and external hardware needed to run code) has allowed me to validate my code base from one through eight cores and has made debugging of the kernel a snap. I've worked with a lot of architectures and development systems from many vendors, but Simics is simply the easiest embedded software prototyping environment I have used. I am also testing the kernel on an MPC8572-based hardware platform with a BDI-3000 debugger, but it is nowhere near as productive.

Up to now, I have used Simics to debug and test a bare-metal multi-core system bring-up, synchronization primitives (barriers, spinlocks) and low-level drivers for PIC, UART, clocks and exception processing. Reverse execution and scripting have been especially useful in helping to debug race conditions, interrupts and booting issues, which are usually incredibly tricky to debug with JTAG or hardware probes, since they are all intermittent and often time-dependant issues.

We are also working on possibly bringing Simics to the classroom for embedded programming labs.

Down the road, we hope to be able to target the QorIQ P4080 cycle-accurate model so that even more progress can be made in the development of multicore robust partitioning. Some of the most difficult problems being tackled right now in this field are WCET (worst-case execution time) estimation and resource-allocation and schedulability analysis in partitioned systems. These problems can benefit from comparing analytical solutions to actual implementations on current and upcoming complex computer architectures.

JE: As a side note, I actually worked on WCET analysis for my own PhD thesis. There are a lot of details that can affect predictability in multicore SoCs with many shared resources. Do you have any exciting results to share yet?

TCV: Robust partitioning implementation such as ARINC-653 mandate the use of a two-level scheduling scheme with static schedules employed for partition switching, and then fixed-priority scheduling for threads (tasks) in each partition. The AMP case where all cores would share scheduling quanta, but no two cores would ever share data from the same partition, appears to be the most tractable case.

The more interesting case of SMP static scheduling, where applications can be spread over several cores for the same partition time interval, is much more problematic than we had initially hypothesized. This is because of the difficulty of providing a usable parallel programming model without breaking space and time partitioning assumptions.

This picture shows an SMP time partitioning static schedule, with a problem spot at the partition context switch point.

JE: I don't immediately understand the problem. Could you explain it in some more detail?

TCV: The robust partitioning kernel is an hypervisor in this case. The hypervisor must ensure that partition switches occurs at the right time to prevent overruns that could take time away from the next partition. Usually, the static schedule has some slack at the end of every schedule slot, to account for the overhead in partition switching. That slack must also account for overhead in hypervisor calls, like the case where we would do an IPC hypervisor call just before the partition switch time. One example would be the partition OS doing a hypercall to effect a "return from virtual interrupt".

In the SMP case, the programmer of the system software expects an abstraction where all cores are always active at the same time for each partition. However, since the hypervisor partition switch can happen with small differences in timing on each core, we can have odd situations.

An example would be that cpu1 acquires a spinlock for a short mutual exclusion, but gets switched-out by the hypervisor before having had time to release the lock. If cpu0's hypervisor runtime has not yet triggered the partition switch, because of jitter and timing differences, problems start to show up. Suppose that cpu0 also tries to acquire the lock. It will spin for much longer than anticipated, basically until the end of the partition time slice. Hundreds if not thousands of cycles can be "stolen" this way, which could throw off schedulability analysis. The application development team, assuming the lock would be held very shortly, might not have taken proper steps to ensure that this implicit lock-holder preemption was mitigated.

There are many corner cases like these that need to be handled. We don't want the programmers of system and application software to have to consider and take care to address them all, as that is not a tenable programming paradigm. For the example I just mentioned, there are software solutions at the hypervisor level that can eliminate it, but always at the cost of complexity or decreased processor utilization. In some other cases, common assumptions about SMP systems are completely trumped by the safety mechanisms in the hypervisor. That's another reason why I believe AMP schedules with no explicit dependency or sharing between cores are simpler in many respects. Maybe I'll prove myself wrong by the end of my project :)

JE: Ouch, that hurts... I can see how you end up with worst-case assumptions being added to worst-case assumptions until you eat up a significant portion of the time slice. Nothing you want regular programmers to have to concern themselves with, certainly.

Let's get back on the Simics track. I think I saw that you did some smart things with Simics to let you focus on the essential problems and not the accidental problems of your target system.

TCV: On a more practical side, I have been experimenting with different ways of simplifying low-level embedded development with Simics. I have recently blogged about using the fact that Simics is a functional simulator to make prototyping easier. It's easy to forget that sometimes the main problem to solve is completely decoupled from the low-level aspects of the system.

Having a super-optimized implementation of a driver that works identically between the virtual hardware and the real system is sometimes required. However, you can often simply replace entire portions of a system with behavioral equivalents that use the functional simulator's introspection capabilities. For instance, before sitting down to write a working multi-core timebase synchronization scheme, I coded a "magic instruction" that simply forced a full system clock synchronization from behind the scenes. I could replace tons of runtime and significant debugging time by less than 10 lines of Python code. The rest of the kernel did not care about whether the clock synchronization was based on my code or some virtual platform tricks.

JE: Could not agree more. Do you have any other technical tid-bits to share?

TCV: My technical blog is at http://www.tentech.ca. It is a mix of embedded systems work, hardware design projects and open-source tools. I used to have "train projects" which progressed every day on the commuter train when I was back in Montréal. Nowadays, they are "after-the-baby-is-asleep" projects :) I often post about solutions I find to my everyday work problems and that includes some nice ones about Simics.

Another interesting aspect I have been writing about is the use of live instrumentation and code patching to find bugs and try bugfixes in exception-handling and interrupts code. That part of embedded systems development is usually a terrible time sink, especially when no usable simulator is available.

JE: I saw your online movie about that. I have one comment on the methodology there though. You should use the "clear-recorder" command after patching the target code, to make sure that there was no residual recording of the future of the system which could cause strange artefacts to happen.

For more on Simics in academia, see my blog post about academic Simics, and my interview with Girish Venkatasubramanian who is doing research on hypervisors.

References

No academic write-up of a subject is complete without some references. In the text above, we find:

[1] R. Walter and C. Watkins, “Genesis platform,” in Digital Avionics Handbook, C. R. Spitzer, Ed. Taylor & Francis Group LLC, 2007, vol. 2, ch. 12, pp. 12–1 – 12–28.

[2] J. W. Ramsey. Integrated modular avionics: Less is more. Avionics Magazine, Access Intelligence LLC, February 2007.

[3] R. N. Mahapatra, P. Bhojwani, and J. Lee, “Microprocessor evaluations for safety-critical, real-time applications : Authority for expenditure no. 43 phase 2 report,” Federal Aviation Administration, Washington, DC 20591, Technical Report DOT/FAA/AR-08/14, June 2008.

[4] ARINC, Inc, Avionics Application Software Standard Interface, Part 1- Required Services, ARINC, Inc Specification 653P1, Rev. 2, Mar. 2006.

[5] L. Kinnan, “Use of multicore processors in avionics systems and its potential impact on implementation and certification,” in Digital Avionics Systems Conference, 2009. DASC ’09. IEEE/AIAA 28th, Oct. 2009, pp. 1.E.4–1 –1.E.4–6.

[6] A. Crespo, I. Ripoll, and M. Masmano, “Partitioned embedded architecture based on hypervisor : The xtratum approach,” in Dependable Computing Conference (EDCC), 2010 European, Apr. 2010, pp. 67–72.

Bringing Home the Science Bacon

By Mike Deliman

MRO recently passed a milestone of bringing back more data than all previous deep space missions combined.  To do this MRO was equipped with a large dish antenna and powerful radio, and is running a more powerful computer than it's companions on and orbiting Mars.  It gets a fair share of antenna time from the DSN antennae on the ground.

Science means collecting data, processing it for it's information, and analyzing the information.  All of these activities can be greatly facilitated by some degree of computer assistance. When it comes to remote-operated scientists (rovers, gliders, orbiters, diggers, swimmers, crawlers, hover-ers..) the computer has to do all the work.

Where it comes to an autonomous robot, or even partially autonomous, a balance must be struck between the amount of data that can be brought back (telemetry bandwidth), the amount of data collected by the science instruments, the amount of processing it takes to turn the data into information, and the processing ability of the computer(s) in the robot.  If the largest gating factor is the bandwidth, and you can gain 10x the science return by processing the data first, you may limit how much data you collect in favor of processing it into information.  If your biggest limitation is processing power, you may just concentrate on getting data off of science instruments and ready for transmit back.  The typical deep space mission has both challenges, and more.

There are terrestrial applications that have similar challenges.  Remote sensing networks, deep sea ROVs and robots, and some industrial applications, as well as military applications, may need to operate independently for periods of time, storing data for upload at the "next" connection.  There could be limitations on storage, processing ability, power, connection bandwidth. 

Some of the solution could be to run multicore.  You may be able to run a multicore chip at a reduced clock rate to save power and gain more processing power than a similar single-core chip at full clock speed.  By increasing the processing power, and using mixed methods (SMP,AMP) as in Mark's "Sea Of Cores...Now What?" discussion, you may be able to handle both steering data and processing it into information. This could increase the science return of the mission.  But with multicore, how do you balance the trade-offs and where do you focus your increase in processing power?

By simulating the whole affair you may be able to gauge how fully loaded your system is.  If you have processing power left, and also important, data steering capacity left, you may be able to share your telemetry stream with another project.  This is part of what NASA has done with the satellites orbiting Mars and the MER and Phoenix robots. The robots collect their data and do what processing they can, storing the results.  They are designed to send data directly to Earth, and do.  When possible, they can also transfer data to the satellites, borrowing some of their bandwidth.  By using a little slack-time in the orbiter's schedules, they're increasing the science return of the robots on the surface.

Increasing the processing power of one key system can increase the data-product returns of an entire group of systems. It can increase the returns both in terms of the quantity of data and quality of information returned.  With careful planning, the "more remote" systems can be coordinated to take advantage of data-stream offload, perhaps doing some data processing, or just collecting more raw data.  Prudent use of a virtualized / multicore system could be one great way of doing this.

None of the current Mars robots are empowered with multicore - when they were designed multicore wasn't as prevalent as today, and there are still very few multicore chips designed for the rigors of space.  There are plenty of off-the-shelf chips with multiple cores available.  Terrestrial based applications can start benefiting from SMP/AMP systems today.

Virtually... Not Yours

By Mike Deliman

So with all this virtualization going on, one computer can run multiple copies of an OS (or multiple OSs), all acting like they own the whole computer. With only some fancy shim layer keeping them from corrupting themselves and everything else, what are the implications for security?  Security is an issue that has been raised more frequently as computers have become more powerful and the network more pervasive.  I mean, viruses spread fast enough when the World Wide Web was mostly single computers with modems dialing up to servers.  In this day of broadband everywhere and constant connections,  doesn't virtualization present a special problem? Doesn't a machine running 10 virtual servers just mean that a virus gets to invade 10 servers for the price of entering one machine? Let the SPAM flow!  NOT!

The problems mentioned are part of an ongoing concern for both the desktop world and the embedded world.  There are standards, and evaluation labs, and  certifications that can be obtained.  They mean "This computing platform can replace several physical computers with one physical computer providing several virtual computing environments, and keep them sufficiently separate so as to protect each one from all the others."  Most of these - such as ARINC 653 and MILS, set forth specifications for systems to satisfy in order to obtain a certification.  These certifications can be issued according to the importance of the system being certified; for example to something like "DO-178B level A" or "EAL 6+" for a system of high criticality (life-critical functions, "if it fails, people die").  Though these standards may not use the word "virtualization" outright, the services they require can be provided by a robust virtualized system.

Among the things these standards can do for us:  provide for protections that would prevent a problem in any one virtual environment from affecting any other.  A virus could corrupt and crash a virtual server, the supervising software could shut down and destroy, and rebuild that virtual environment, starting with a clean slate.  "No Virus, Bad Virus...  NOT YOURS!"  This oversimplifies the whole idea, but you get the picture.  If one virtual machine crashes, it's not going to affect the entire system, the other virtual machines keep running.  You might lose that powerpoint presentation you were "researching", but the feedback from the UAV being displayed, the real-time map updates, and the status of your deployed troops will still continue unaffected by the loss of that document or the restart of the OS that was affected by it.

Today we're announcing  VxWorks MILS, currently under  evaluation to EAL6+.  Now then... what about multicore?  :-)

Virtually Yours...

By Mike Deliman

This morning we've made a couple of announcements that will hopefully surprise and delight the Real Time computing community.  Wind River is releasing two new products that have their base in  virtualization: Wind River's Hypervisor, and Wind River's MILS 2.0.  Both of these products introduce platform virtualization, used in different ways.   Wind River's implementations allow for a "floatilla" of OS's" to be run amongst a "sea of Cores" - it can be run as a one-to-many, many-to-many, or many-to one configuration (that is with SMP, one OS can be run by many cores, the Hypervisor is capable of running / scheduling many OS's among many cores, and both the Hypervisor and MILS 2.0 are capable of running many OS's over one shared core).

Both of these products are very high-powered and sophisticated.  Both products are designed with an eye to the future.  The Hypervisor itself can be used in SMP, AMP, Supervised-AMP and cooperative multicore configurations, and can also be configured to paravirtualize several Operating Systems and run them all (time-share style) on a single core.  The MILS 2.0 product is designed specifically to paravirtualize OS's and run them on a single shared-core with a high degree of separation maintained by the MILS 2.0 separation kernel.

Many of our customers have built multiprocessor systems, sometimes because there wasn't enough horsepower on one board to handle the needs of their system, sometimes because of a need to keep data processing nodes separate (security).  With today's processors, you may be able to replace a multi-board system with either a single multicore board running Hypervisor or a single board running a modern (single) core with our MILS 2.0 separation kernel.  Both products allow a number of instances of VxWorks to run on paravirtualized platforms, or run without an OS at all (bare-metal or minimal executive, etc), and the Hypervisor also supports Wind River's Linux on paravirtualized platforms.

So what is virtualization?  I think of virtualization as a star-trek like copy machine, where you start off with a computer, and make "virtual" copies of it.  The copy can have anything that's already on the real machine, or a subset of those features.  The Hypervisor schedules those copies to run on the real machine, making them believe they are completely in control.  This can allow you to replace several older machines with one virtualized machine and get the same work done.

Some popular examples include VMware, Parallels, and QEMU.  These are all available for desktop machines, allowing users to create polymorphic environments.  These are mostly "type-2" hypervisors, meaning the hypervisor is a guest running under a main operating system and is subject to the whims of that OS.  Wind River's implmentations are "Type 1", meaning our Hypervusor runs as the only supervisory access code on the system and has absolute control over the system.

I'm pretty excited about this.  It brings supercomputing into the embedded realm!

Processing Paradigm: it's all about capacity

By Mike Deliman

When I was a kid anything that was a computer, or had one in it, was pretty obvious. Computers weren't "just everywhere".  Now we've got multiple CPU chips on a board, multiple CPU cores on a chip, different kinds of cores on a single chip, multiple computer boards in a single chassis, ... it goes on.    These things are embedded in everything around us, all this hardware glued together to achieve something.
This brings us to software.  Software has to evolve to keep up with hardware, and with the needs of users.  With all these cores and chips and boards and systems running around, it gets a bit confusing.   Software is what enables everything from multi-processing to "poly-processing".  There's a lot of buzzwords about it - SMP, AMP, POS, VOS, Real time kernel, Separation Kernels... but what does it all mean?  And.. what's it for?

Eventually these things will all become even more blurry. As the realization that the "system" is a composite of the hardware and software all together spreads beyond the aerospace and defense industries, the various specifications will have to cover a fusion of SMP, AMP, and partitioned systems.

For now, though... what I'm talking about includes:
SMP - Symmetric  Multi-Processing - two or more cores running out of the same RAM, each processing parts of a shared task.   The cores may or may not run the same exact OS, but often do.
AMP - Asymmetric Multi-Processing - this is where several separate computers process data as parts of an overall larger system.  They may briefly share data, or have a limited amount of shared memory, but other than this each computer is a separate processing node.
SMP is comparatively  new, but AMP has been available through packages like vxMP for a long time.
SMP and AMP are multi-processor applications, where multiple computers are connected together to achieve a larger goal.  They both bring up issues of concurrency, and offer their own challenges for the implementer.

Way on the other end of the scale are what might be called "poly-processing computers" partitioned systems, where a single computer is virtually carved up and treated as if it's really several computers.   Each of those virtual computers can run a completely different OS - one for it's rich applications and ease of install, one for it's sophisticated communications abilities and firewall, perhaps even a third or forth to handle other kinds of processing. or devices.  You can already share a PC between Windows and Linux (for example) using virtual machine software technologies.  But did you know that similar things are being done with flight systems - using a single high-powered computer to replaces dozens of of single-purpose computers, to reduce weight, cost, and complexity? 

SMP and AMP are for systems where one CPU can not possibly handle the work load before it.   If the work can all be done in one "space" -simultaneously acquire data, process data in place, store data - SMP is a good fit, as all the processors run out of one pool of RAM.  One processor can be tasked with managing / storing the pools of data, another can perform the processing-in-place.

If the work should be handled in separate spaces - say the processing can't be done in-place for whatever reason - AMP would be a better fit. 

In the case of poly-processing (via vitalization, etc), this paradigm fits more where you want to take advantage of the extra processing power of a modern computer to have it replace a number of older computers (or other devices), to save on weight and expense of a newer system with similar function.  A Good examples of this could come from the shipbuilding and aircraft industries, where you have multiple separate mechanical and computational systems that may easily be replaced with smaller, lighter, more capable modern electronics.  Each of these separate systems might still need a small general purpose computer to control them, but that can be costly and add weight.   A single, modern, high-powered computer may be able to replace dozens of smaller, less capable systems.

With any of these paradigms it all comes down to: what is your application, how does it need to be accomplished, and does your system have enough processing capacity to achieve your goals.