The isolation imperative: protecting software components in an ISO 26262 system

Software components can be impolite, if not downright delinquent. For instance, a component might:

• rob other components of CPU time
  
• rob other components of file descriptors and other system resources
  
• access the private memory of other components
  
• corrupt data shared with other components
  
• create a deadlock or livelock situation with other components
  

Shameful, I know. But in all seriousness, this sort of behavior can wreak havoc in a safety-critical system. For instance, let's say that a component starts to perform a CPU-intensive calculation just as the system enters a failure condition. Will that component hog the CPU and prevent an alarm process from running?

The answer, of course, is that it damn well better not.

It becomes important, then, to prevent components from interfering with one another. In fact, this principle is baked into the ISO 26262 functional safety standard for road vehicles, which defines interference as:

"...the presence of cascading failures from a sub-element with no ASIL [Automotive Safety Integrity Level] assigned, or a lower ASIL assigned, to a sub-element with a higher ASIL assigned leading to the violation of a safety requirement of the element”

To put it crudely, less important stuff can't stop more important stuff from happening.

So how do you prevent interference? One approach is through isolation. For instance, a system may implement spatial isolation between application processes. This would include mechanisms for interprocess communication and interprocess locking that prevent one process from inadvertently affecting another.

Mind you, there are multiple types of interference, so you need to implement multiple forms, or axes, of isolation. Time for a picture:




In general, you need to determine what does, and what doesn't, need to be isolated. You also need to identify which components are apt to be delinquent and build a cage around them to protect more critical components. Which brings me to a recent paper by my inestimable colleagues Chris Hobbs and Yi Zheng. It's titled "Protecting Software Components from Interference in an ISO 26262 System," and it explores techniques that can help you:

• implement the component isolation required by ISO 26262
• demonstrate that such isolation has been implemented

And while you're at it, check out the other titles in our "safe" whitepaper series. These include "The Dangers of Over-Engineering a Safe System" and "Ten Truths about Building Safe Embedded Software Systems."

And don't worry: there's nothing delinquent about downloading all of them.

This post originally appeared in the QNX auto blog.

Can a safety-critical system be over-engineered?

Too much of a good thing?

It's a rhetorical question, of course. But hear me out.

As you can imagine, many safe systems must be designed to handle scenarios outside their intended scope. For instance, in many jurisdictions, passenger elevators must be capable of handling 11 times more weight than their recommended maximum — you just never know what people will haul into an elevator car. So, if the stated limit for a passenger elevator is 2000 pounds, the actual limit is closer to 22,000 pounds. (Do me a favor and avoid the temptation to test this for yourself.)

Nonetheless, over-engineering can sometimes be too much of a good thing. This is especially true when an over-engineered component imposes an unanticipated stress on the larger system. In fact, focusing on a specific safety issue without considering overall system dependability can sometimes yield little or no benefit — or even introduce new problems. The engineer must always keep the big picture in mind.

Case in point: the SS Eastland. In 1915 this passenger ship rolled over, killing more than 840 passengers and crew. The Eastland Memorial Society explains what happened:

"...the Eastland's top-heaviness was largely due to the amount and weight of the lifeboats required on her... after the sinking of the Titanic in 1912, a general panic led to the irrational demand for more lifesaving lifeboat capacity for passengers of ships.

Lawmakers unfamiliar with naval engineering did not realize that lifeboats cannot always save all lives, if they can save any at all. In conformance to new safety provisions of the 1915 Seaman’s Act, the lifeboats had been added to a ship already known to list easily... lifeboats made the Eastland less not more safe..."

There you have it. A well-intentioned safety feature that achieved the very opposite of its intended purpose.

Fast forward to the 21st century. Recently, my colleague Chris Hobbs wrote a whitepaper on how a narrow design approach can subtly work its way into engineering decisions. Here's the scenario he uses for discussion:

"The system is a very simple, hypothetical in-cab controller (for an equally hypothetical) ATO system running a driverless Light Rapid Transit (LRT) system...

Our hypothetical controller has already proven itself in Rome and several other locations. Now a new customer is considering it for an LRT ATO in the La Paz-El Alto metropolitan area in Bolivia. La Paz-El Alto has almost 2.5 million inhabitants living at an elevation that rises above 4,100 meters (13,600 ft.—higher than Mount Erebus). This is a significant change in context, because the threat of soft and hard memory errors caused by cosmic rays increases with elevation. The customer asks for proof that our system can still meet its safety requirements when the risk of soft memory errors caused by radiation is included in our dependability estimates..."

So where should the engineer go from here? How can he or she ensure that the right concerns are being addressed? That is what Chris endeavours to answer. (Spoiler alert: The paper determines that, in this hypothetical case, software detection of soft memory errors isn't a particularly useful solution.)

Highly recommended.

All roads lead to QNX at embedded world 2013

Montreal, my home town, was once known as a city of churches. So much so that Mark Twain famously quipped, "this is the first time I was ever in a city where you couldn't throw a brick without breaking a church window."

If Mr. Twain were alive today and able to visit embedded world 2013, he might make a similar comment about QNX. Because it seems that, wherever you turn at embedded world, someone is demonstrating a QNX-based system.

Multimedia and wireless demos
First stop is the QNX booth, where you'll find a natty new demo designed to showcase our support for wireless, video, and HMI technologies. Among other things, the demo shows how QNX lets you work with a mix of application and graphics environments, including Qt 5.0, OpenGL ES 2.0, and Crank Software’s Storyboard Suite.

Power up the demo, and you'll see several applications, including a medical monitor:



and a speedometer:



You'll also find games, a digital thermostat, a photo viewer, an audio meter, and several other demo apps. And did I mention? You can find two of these demo systems in the QNX booth, one based on a Freescale i.MX 6 SABRE Lite board and the other on a TI AM335 Starter Kit board.

PLC demos
If you're a hard-core industrial developer, be sure to catch the two programmable logic controller (PLC) platforms in the QNX booth. These platforms were a group effort: QNX provided the OS; companies like IsaGRAF, KW-Software, and koenig-pa provided the ladder logic and EtherCAT software; and Freescale and TI provided the hardware — one platform is based on a Freescale QorIQ TWR-P1025 Tower System Module, the other on a TI Sitara AM335x ARM Cortex-A8 processor.

The purpose of these platforms is simple: to reduce the time and cost of developing PLCs and other industrial systems. If you're interested, the eval software for the platform based on the Freescale module is now available for download from the QNX website.

QNX CAR platform demo
No, we didn't drive the new QNX concept car to embedded world. But we did bring a demo of the QNX CAR application platform, and from what I hear, it's driving lots of booth traffic (pun fully intended). Here's a snap of the demo, taken on the show floor:



Lotsa partner demos
Take a walk down the aisle, and you'll soon come across several other vendors showing QNX-based systems. Here are the ones we've identified so far:

Acontis is demonstrating its EC-Motion EtherCAT motion library running on the QNX Neutrino RTOS and a TI Sitara AM335x ARM Cortex-A8 processor. Hall 1/1-538.

Crank Software is demonstrating an automotive demo based on the QNX CAR application platform. Hall 4/4-330.

Digia is demonstrating “Qt 5 on the QNX platform – a Cinematic Experience,” which will show many new features in Qt 5 Qt Quick 2. Hall 4/4 – 520.

Freescale and koenig-pa are demonstrating a PLC reference platform that integrates koenig-pa EtherCAT protocol software, ISaGRAF PLC firmware, and the QNX Neutrino RTOS on a Freescale dual-core QorIQ P1025 processor. Hall 4A/4A-206 and Hall 5/5-425.

KDAB is showcasing an IP camera demo written in Qt5 and QML, and running on the QNX Neutrino RTOS and a Freescale i.MX 6 SABRE Lite ARM Cortex-A9 platform. Hall 4/4-622.

KW-Software is demonstrating a PLC development platform developed in collaboration with QNX Software Systems, TI, and koenig-pa. Hall 1/1-446.

MPC Data, a Bsquare Company, is showcasing a high-performance graphics demo based on OpenGL and the QNX Neutrino RTOS. Hall 4A/4A-108.

Xilinx is showcasing a high-precision, low-noise, multi-motor electrical drive demo running on the QNX Neutrino RTOS. Hall 1/1-205.

For more details on these demos, check out the press release that QNX issued this morning.

The joy of talking
Several QNX experts are presenting technical talks at embedded world:

• Clear SOUP and COTS Software for Safety-Critical Systems — Tues, Feb 26, 14:00 - 14:45, Session 03
• The Joy of Scheduling — Thurs, Feb 28, 10:00 - 10:30, Session 19
• Ten Truths about Building Safe Software — Thurs, Feb 28, 14:15 - 15:00, Session 21
• Issues in M2M Communication for Software and Firmware Updates — Thurs, Feb 28, 16:30 - 17:00, Session 24

So, if for some strange and inexplicable reason, you want to avoid all things QNX, don't go to embedded world this week. Because once you arrive, there will be no escape. :-)

Acontis releases new EtherCAT motion library for QNX Neutrino operating system

This just in: Acontis, a leading provider of EtherCAT software and realtime hypervisor technology, has announced that its new EC-Motion product is now available for the QNX Neutrino operating system.

So what, exactly, is EC-Motion? In a nutshell, it's a C/C++ motion control library for EtherCAT drives (i.e. the electronic systems that control industrial motors).

According to Acontis, the EC-Motion library supports all of the single-axis movement commands specified in the PLCopen standard, eliminating the need for additional (and costly) hardware. It also allows the developer to:

• implement applications for multi-axis coordinated movements
• operate EtherCAT drives in cyclic synchronous position mode (CSP) or cyclic synchronous velocity (CSV) mode
• easily integrate the EC-Motion library into custom motion applications as well as into a programmable logic controller (PLC) runtime environment

Here's the EC-Motion architecture at a glance:



Demo on BeagleBone computer
Acontis also announced that it will demonstrate EC-Motion for QNX at the embedded world conference, from February 26 to 28 in Nuremberg. The demo will run on a BeagleBone, a credit-card-sized computer based on Sitara ARM AM335x Cortex-A8 processors from Texas Instruments. The demo will show a Yaskawa Sigma-5 EtherCAT drive running in cyclic synchronous velocity mode.

If you plan to attend embedded world, you can catch the demo at the IXXAT Automation GmbH stand, Hall 1/1-538.

For more details, read the Acontis press release.

10 truths about building safe embedded software systems

I wish I could remember his exact words. But it has been a long time — 20 years — and my memory has probably added words that he never wrote and removed words that he did write. That said, this is how I remember it:

"We all strive to write bug-free code. But in the real world, bugs can and do occur. Rather than pretend this isn't so, we should adopt a mission-critical mindset and create software architectures that can contain errors and recover from them intelligently."

The "he" in question is my late (and great) colleague Dan Hildebrand. I'm sure that Dan's original sentences were more nuanced and to the point. But the important thing is that he grokked the importance of "culture" when it comes to designing software for safety-critical systems. A culture in which the right attitudes and the right questions, not just the right techniques, are embraced and encouraged.

Which brings me to a paper written by my inimitable colleagues Chris Hobbs and Yi Zheng. It's titled "Ten truths about building safe embedded software systems" and, sure enough, the first truth is about culture. I quote:

"A safety culture is not only a culture in which engineers are permitted to raise questions related to safety, but a culture in which they are encouraged to think of each decision in that light..."

I was particularly delighted to read truth #5, which echoes Dan's advice with notable fidelity:

"Failures will occur: build a system that will recover or move to its design safe state..."

I also remember Dan writing about the importance of software architectures that allow you to diagnose and repair issues in a field-deployed system. Which brings us to truth #10:

"Our responsibility for a safe system does not end when the product is released. It continues until the last device and the last system are retired."

Dan argued for the importance of these truths in 1993. If anything, they are even more important today, when so much more depends on software. If you care about safe software design, you owe it to yourself to read the paper.

Prefer your whitepapers in German? Have I got a link for you

Germany has long been a strong market for QNX technology, particularly in the industrial, medical, and automotive sectors. Consider, for example, the many cars from Audi, BMW, Mercedes, and Porsche that ship with QNX technology on board.

It's no surprise, then, we've been redoubling our efforts to publish our latest technical whitepapers in German. So if you sprechen sie Deutsch (I hope I said that right) better than you speak English, I invite you to visit the German section of our whitepapers page.

Papers include:

Wann genau benötigt man ein Echtzeitbetriebssystem?

Funktionale Sicherheit komplexer Software-Systeme – Teil 1

HTML5 – die Zukunft des In-Car Infotainment?

For the full list of papers, click here.

Using Crank Storyboard to create an automotive user interface

Just how adept is the QNX CAR application platform at supporting a variety of user interface technologies and toolkits?

From the beginning, we've promoted flexibility as a key quality of the QNX CAR application platform. For instance, the platform lets you work with a variety of user interface technologies, including HTML5, Qt, OpenGL ES, and others. What's more, it lets you blend UI components built with different technologies on the same display, at the same time. You're not forced into using a single API or toolkit.

When it came time to build our new technology concept car, we decided to put this flexibility to the test. After all, the whole point of the concept car is to demonstrate the capabilities of the QNX CAR platform. So, for the first time, we tried building a user interface with the Storyboard Suite from Crank Software.

How well did the QNX CAR platform and Storyboard work together? I think the results speak for themselves. For instance:



Of course, this photo can't demonstrate the smooth animations and snappy performance of the car's user interface. For that, I recommend one of the videos shot at CES, including the excellent video from TI.

So why did we choose Storyboard? For one thing, it allowed our concept team to take UI components created in Photoshop and import them directly into their live design. Rather than spend days or weeks recreating the UI in code, the team's engineers were able to start with what the UI designer provided. Which made prototyping and fine-tuning the UI a lot easier.

Mind you, that wasn't the only reason the team used StoryBoard. But instead of listening to me blather about it, check out this video:



Key takeaway: If you're building a UI for your QNX-based system, you owe it to yourself to check out Crank's Storyboard Suite. You can learn more on the Crank website.

Evaluation software for EtherCAT "PLC in a box" now available for download

In August, I introduced you to a brand new PLC reference platform created by Freescale, IsaGRAF, KPA, and QNX Software Systems. The purpose of the platform is simple: to provide a pre-integrated solution that can significantly reduce the time and cost of developing PLCs and other industrial systems.

Good news is, the software stack for the platform is now available for download. Here's what you get:

• ISaGRAF PLC firmware
• ISaGRAF 6 workbench for IEC 61499 and IEC 61131-3 standard PLC programming languages
• KPA EtherCAT master stack
• KPA EtherCAT Studio
• QNX Neutrino RTOS for the Freescale QorIQ P1025 tower module

To download the platform software, visit the QNX website — you'll need to set up a MyQNX account, if you haven't already. To run the platform software, you'll need a Freescale P1025 tower module, target slaves, and some software utilities. To learn how to obtain these components, visit the Freescale website.

Taking a long, hard look at the ozone hole

For more than 20 years, a Harvard research team has been taking QNX technology to stratospheric heights

The NASA ER-2 high-altitude
aircraft

Hey, do you remember when everyone was in a knot over the ozone hole? You know, the one over Antarctica? The one the size of Antarctica? Based on all the press it has received lately (read: not much), it is yesterday's problem. I, for one, haven’t worried about it — or even thought about it — for a good 10 years.

But here’s the thing. The ozone hole didn’t go away. And it’s not going away soon. Yes, evidence suggests that the hole will heal, but the process promises to take decades — by 2050, if we’re lucky. (Strictly speaking, the hole heals every Austral Spring, but only temporarily; it always returns the next Austral Winter. And it isn’t exactly a hole, since the ozone doesn’t disappear completely from the upper stratosphere. It does disappear from the lower stratosphere, however.)

Did I mention only one hole? Sorry to mislead you. There are, in fact, substantial ozone losses over the Arctic as well, with the loss during the winter of 2011 achieving ozone hole status.

Ozone depletion is serious stuff. It may contribute to an enormous list of problems, from crop failures to eye cataracts to skin cancer. So it’s important to do the hard science and measure its progress, along with any factors that can affect it. Otherwise, how do you argue for a cogent policy on controlling substances and industrial practices to prevent ozone depletion? And do you know whether the policies and practices you put in place are doing any good?

Problem is, measuring and analyzing ozone depletion is a long-term project that takes patience and commitment. Fortunately, the Anderson Research Group from Harvard University seems to have those qualities in spades.

Making the upgrade
The group has been operating continuously since 1979. (For context, that was the year that Philips demonstrated the first Compact Disc. Remember those?) For the first few years, the group used a balloon to carry their instruments high into the atmosphere, but with the discovery of the Antarctic ozone hole in the mid-80s, they graduated to a NASA ER-2 high-altitude aircraft, which flies as high as 21 kilometers. (If the ER-2, depicted above, looks to you like a modded U-2, you’re right.)

The team’s first QNX-based instrument,
which measured OH in the lower
stratosphere, was deployed in an ER-2.

Lots of things have changed since 1979, but for the past two decades, one thing hasn’t: the group’s use of QNX technology. It all started in 1990, when the group decided to replace their homegrown OS kernel with the QNX RTOS v2. They then upgraded to the QNX RTOS v4 in 1992, which is also when they deployed their first QNX-based system, an instrument that measured OH (hydroxyl radical) in the lower stratosphere. More recently, they migrated to the latest generation of the QNX technology, the QNX Neutrino RTOS, aka v6.

Alphanumeric soup
To measure phenomena in the stratosphere, the team created a data acquisition architecture that takes advantage of core QNX strengths, including multitasking, message passing, realtime performance, and transparent distributed networking. Flexibility is a key characteristic of this architecture, since it must support a variety of instruments that measure an alphanumeric soup of airborne radicals and reactive intermediates. These include BrO, ClO, ClONO2, ClOOCl, NO2, OH, HO2, O3, CH4, N2O, CO, and CO2, as well as water vapor, water isotopes, and total water. (Why measure water? Because its presence in the stratosphere can contribute to ozone depletion. And because the increased frequency of heavy storms, such as Hurricane Sandy, may inject more water into the stratosphere.)

Here is the full configuration of the data acquisition architecture, which includes control and acquisition programs running on a flight computer as well as display and interactive commands running on a ground support computer:



According to Norton Allen, a software engineer for the Anderson group, “From the start, we needed an OS platform that would scale with our growing requirements, and that would satisfy our demands for high reliability — sending a plane into the lower stratosphere is a costly proposition, so there’s no room for software failures. At the same time, we needed a standards-based platform that would let us write portable applications. The QNX OS has been able to deliver on all counts."

Global scale
I’ve barely touched on the many research activities of the Anderson Research Group. To quote their website, the group “addresses global scale issues at the intersection of climate and energy using a combination of experimental and theoretical approaches drawn from the disciplines of chemistry, physics and applied mathematics.” So if you’ve got a minute, visit the site. Who knows, you may learn something — I did.

New webinar: PLCs made easy

PLC reference platform
from Freescale, QNX,
ISaGRAF, and KPA

Okay, I'll admit it, creating anything of value is never that easy. The details always get in the way. But every once in a while, a tool comes by that can make your job easier. Not to mention faster.

That's the idea behind the new Programmable Logic Controller (PLC) reference platform from Freescale, QNX Software Systems, ISaGRAF, and KPA. By pre-integrating EtherCAT software, PLC firmware, and a realtime OS on a dual-core processor, the platform allows design engineers to spend less less time on underlying plumbing — which means they can get to the application stage sooner. And who can argue with sooner?

If you'd like to know more about this new platform, check out the upcoming webinar hosted by Chris Ault, a product manager at QNX, and John Ralston, a system architect at Freescale. Here are the coordinates:

PLC Made Easy: A Day in the Life of Developing a Pre-Integrated EtherCAT Programmable Logic Controller

Tuesday, December 4; 11:00 am to 12:00 noon EDT

Registration: Open Systems Media

QNX versus Linux: Which is best for IEC 62304 medical devices?

A few weeks ago, I invited you to a webinar on this very topic. If you missed the webinar, no worries: the archived version is now available for download. And speaking of downloads, you can now read the accompanying whitepaper, written by my inimitable colleague Chris Hobbs.

If you're wondering whether the paper is for you, here's the official summary:

This paper is for anyone who must select an OS for a safety-critical medical system. It provides information to help with estimates of the real cost of choosing a Linux or QNX OS. It lists requirements identified by standards such as IEC 62304, ISO 14971 and IEC 61508, and offers comparative estimates of the effort required to meet these requirements. These estimates are for initial certification and pre-approval, subsequent re-certifications following OS upgrades, and ongoing costs.

While you're at it, check out these other whitepapers for medical-device developers:

• Clear SOUP and COTS Software for Medical Device Development
• Persistent Publish/Subscribe Messaging in Medical Devices
• Choosing an RTOS for Remote-care Medical Devices

Come to think of it, there's no reason to stop with these, when you can peruse the entire library of medical whitepapers on the QNX website.

In-car infotainment and the art of doing more with less

No, not that kind of squeezing.

Granted, the title for this blog post doesn't have the pizazz of, say, "Zen and the Art of Motorcycle Maintenance." (Are you old enough to even remember that book?) But it does capture the gist of a webinar that my colleague Andy Gryc will deliver next week.

His title for the webinar is "Squeezing high-end technologies into low-end infotainment systems." Admittedly, it's more direct than mine. Which is fitting, given that Andy has direct experience designing in-car systems. OnStar, for example.

But I digress. I'm sure you'd like to know what Andy plans to cover, so here's the overview:

Squeezing high-end technologies into low-end infotainment systems

Today's infotainment systems have it all – full multimedia, mobile device integration, POI-enabled navigation, speech recognition, high-resolution graphics, and cloud connectivity. The only problem is all of these features come with a big price tag.

Join Andy Gryc, automotive marketing manager, for this webinar, where he answers the question: Is it possible to build an infotainment system that meets today's customer demands with yesterday's price tag?

A 50-minute session (plus Q&A), this webinar covers a number of techniques to help slim down your next infotainment's BOM cost; it also suggests ways to target the luxury segment as well as the more cost-conscious, high-volume one with the same basic technology.

Date: Tuesday October 23, 2012

Time: 12:00 pm ET

Duration: 1 hour, including Q&A

Registration: Click here to register

Who should attend: Automotive software engineers and managers

This post also appeared on the QNX Auto Blog.

Which OS for IEC 62304 medical systems?

The question, to some degree, is rhetorical. I work for an OS company, that company has developed a 62304-compliant OS for medical device manufacturers... you see where this is going.

But don't go yet. This week, my colleague Chris Ault will present a webinar on this very topic, and the content he'll cover should prove useful to anyone choosing an OS for a medical device — or, for that matter, any device that must operate reliably and safely.

In case you're wondering, the Linux question will definitely come up. Linux does lots of things very well, but does it belong in a safety-critical device? Knowing Chris, he'll offer a suitably unambiguous answer — and some solid reasoning to back it up.

Okay, enough from me. To learn more about the webinar, which will be held this
Thursday, September 27, at 2 pm eastern, visit the QNX website.

How to keep track of QNX board support packages, without really trying

If you're an embedded developer using the QNX Neutrino OS, it pays to keep up to date on QNX support for the latest evaluation and reference boards. Doing so is easy: just subscribe to the QNX Source newsletter, which provides a monthly update on any new or updated board support packages (BSPs).

The newsletter also provides links to the latest webinars, whitepapers, videos, and press releases — you'll find it the easiest way to stay on top of all things QNX, without really trying.

For instance, here's a sneak peek of the BSP section in the upcoming issue:

BSP Update
Freescale i.MX6Q Nitrogen6x
Freescale i.MX6Q Sabre Board for Smart Devices
Freescale i.MX53 Quickstart
TI AM335x EVM
TI AM335 Beaglebone
TI AM335x starter kit
TI OMAP 3730 Beagleboard-xM

Wireless Drivers
Wireless drivers for LS Research Tiwi Modules are now available for the following reference boards:
TI AM335x starter kit
TI OMAP 3730 Beagleboard-xM

Subscribing to the newsletter is super easy. So what you are waiting for?

Qt Creator 2.6 introduces QNX support

This just in: The Qt developer blog has announced a new release of Qt Creator, the integrated development environment for creating applications and user interfaces based on the Qt application framework. (If you're unfamiliar with Qt, check out these previous posts.)

The new release, version 2.6, is now in beta and introduces two key features: support for the QNX OS and a concept called kits.

According to Eike Ziller of the Qt developer blog, a kit is a user-defined combination of compiler, debugger, Qt version, and target device. As a developer, you can freely choose each kit setting independent of all other settings. For instance, you can mix and match compilers and Qt versions. Qt Creator will warn you if it thinks you're choosing a dumb combination, but otherwise gives you free rein over the configuration.

Kits are new to 2.6 and they replace a concept called targets. Targets served a similar function, but were "hardwired". If you deviated from the default setting of a target, you had to manually change all build and run configurations. But now, with targets, the IDE makes these changes for you.

Qt Creator 2.6 supports both QNX and Android, but doesn't support Symbian. According to Ziller, Symbian support had to be dropped because of a lack of maintainers.

Here's a screen capture of the Kit Preferences dialog:



For details on Qt Creator 2.6, visit the Qt developer blog.