- When it comes to driving, Andy is ready to give up some control
- Paul discovers what it takes to build a Batmobile
- Derek tells the Porsche to find a Starbucks — and it does
- Derek and Mark discover that the Porsche is made of tough stuff
- Paul wants quality time in Jay Leno's garage
- Wielding video evidence, Nancy defeats the naysayers
- Paul discovers a brand new blog
4/30/2012
What has the QNX auto team been up to?
Well, let's see...
4/24/2012
Designing safe software systems? I've got three articles to keep you on track
Believe it or not, the men in this video are performing a safety procedure:
So are the men in this video:
I know what you're probably thinking: What's so safe about standing near, or hanging from, a moving train? Are these people nuts?
On the other hand, you may know exactly what is happening: The men are exchanging railway tokens. In a nutshell, only one token exists for any given section of track, and only the train driver possessing the token can access that section. (If you're a software developer, think mutex.) The idea, of course, is to prevent two or more trains, especially those traveling in opposite directions, from using the same section of track at the same time.
From what I can gather, token-based systems have proved highly effective in preventing train-to-train collisions. Indeed, they remain in use in several areas, particularly on heritage railway lines.
That said, the world of rail transportation has moved on. High-speed freights, such as the TGV postal in France, zoom along at over 250 km/h, while passenger trains, such the China Railway High-speed, carry passengers at speeds reaching 350 km/h. The Shanghai Maglev Train, meanwhile, operates at a jaw-dropping 430 km/h — and is designed for speeds up to 500 km/h.
Available and correct
None of these trains could run without software control systems. Let me re-phrase that: safe software control systems. A safe software system possesses two key characteristics: It always responds when a response is required, and it always provides the correct response.
For instance, the software system controlling a train’s brakes must be available whenever required — a delayed response could result in an accident. The software system must also apply the brakes appropriately — too little can result in a collision, and too much can damage the train or cause a derailment.
To meet these requirements, the software system needs to use a real-time OS (RTOS) that meets specific claims of reliability and availability. But the software that runs on top of the OS (i.e. the part you design) must also embody these qualities. Which is where my colleague Chris Hobbs comes in.
Chris spends a lot of time thinking about the design of safe software systems — when he isn't actually helping people design them. So, not surprisingly, he has produced a series of articles and white papers to ground developers in key concepts and to help companies develop a safety culture. Electronic Design magazine has published three of his pieces so far, and I wouldn't be surprised if they publish more in the future.
Without further ado, here are the Electronic Design articles:
The Limits of Testing in Safe Systems — Key takeaway: Testing can prove the presence of faults, but it can't prove their absence. It isn't enough to test your systems; you must use other methods, such as design validation, as well. That said, testing can tell you a lot, especially when you apply statistical analysis to your test results, and when you use techniques like fault injection to estimate remaining faults and to observe how the system behaves under fault conditions.
Define And State Your Safety Requirements Before Design and Test — Key takeaway: Safety must be built into a system from the start, and everything you do should follow from the premise that all software contains faults and these faults may lead to failures. As you build your system, you must reduce the number of faults included in the design and implementation, prevent faults from becoming errors, prevent errors from becoming failures, and handle failures when they do occur.
Clear SOUP And COTS Software Can Reliably Serve Safety-Critical Systems — Key takeaway: Some device manufacturers want to use COTS software, but worry that COTS means SOUP — software of uncertain provenance. And SOUP can make a mess of safety claims... or perhaps not. If you take a nuanced approach and distinguish between opaque SOUP (which should be avoided) and clear SOUP (for which source code, fault histories, and long in-use histories are available), you may, in fact, discover that COTS software is a good choice for your safety-related project.
So are the men in this video:
I know what you're probably thinking: What's so safe about standing near, or hanging from, a moving train? Are these people nuts?
On the other hand, you may know exactly what is happening: The men are exchanging railway tokens. In a nutshell, only one token exists for any given section of track, and only the train driver possessing the token can access that section. (If you're a software developer, think mutex.) The idea, of course, is to prevent two or more trains, especially those traveling in opposite directions, from using the same section of track at the same time.
From what I can gather, token-based systems have proved highly effective in preventing train-to-train collisions. Indeed, they remain in use in several areas, particularly on heritage railway lines.
That said, the world of rail transportation has moved on. High-speed freights, such as the TGV postal in France, zoom along at over 250 km/h, while passenger trains, such the China Railway High-speed, carry passengers at speeds reaching 350 km/h. The Shanghai Maglev Train, meanwhile, operates at a jaw-dropping 430 km/h — and is designed for speeds up to 500 km/h.
Available and correct
None of these trains could run without software control systems. Let me re-phrase that: safe software control systems. A safe software system possesses two key characteristics: It always responds when a response is required, and it always provides the correct response.
For instance, the software system controlling a train’s brakes must be available whenever required — a delayed response could result in an accident. The software system must also apply the brakes appropriately — too little can result in a collision, and too much can damage the train or cause a derailment.
To meet these requirements, the software system needs to use a real-time OS (RTOS) that meets specific claims of reliability and availability. But the software that runs on top of the OS (i.e. the part you design) must also embody these qualities. Which is where my colleague Chris Hobbs comes in.Chris spends a lot of time thinking about the design of safe software systems — when he isn't actually helping people design them. So, not surprisingly, he has produced a series of articles and white papers to ground developers in key concepts and to help companies develop a safety culture. Electronic Design magazine has published three of his pieces so far, and I wouldn't be surprised if they publish more in the future.
Without further ado, here are the Electronic Design articles:
The Limits of Testing in Safe Systems — Key takeaway: Testing can prove the presence of faults, but it can't prove their absence. It isn't enough to test your systems; you must use other methods, such as design validation, as well. That said, testing can tell you a lot, especially when you apply statistical analysis to your test results, and when you use techniques like fault injection to estimate remaining faults and to observe how the system behaves under fault conditions.
Define And State Your Safety Requirements Before Design and Test — Key takeaway: Safety must be built into a system from the start, and everything you do should follow from the premise that all software contains faults and these faults may lead to failures. As you build your system, you must reduce the number of faults included in the design and implementation, prevent faults from becoming errors, prevent errors from becoming failures, and handle failures when they do occur.
Clear SOUP And COTS Software Can Reliably Serve Safety-Critical Systems — Key takeaway: Some device manufacturers want to use COTS software, but worry that COTS means SOUP — software of uncertain provenance. And SOUP can make a mess of safety claims... or perhaps not. If you take a nuanced approach and distinguish between opaque SOUP (which should be avoided) and clear SOUP (for which source code, fault histories, and long in-use histories are available), you may, in fact, discover that COTS software is a good choice for your safety-related project.
4/23/2012
Why I'm still driving with snow tires
A few weeks ago, Ottawa had a spell of gorgeous, hot, break-out-your-shorts weather. But did I replace my snow tires with all-season radials? No. Did I put away my winter boots? No. Did I take out my lawn mower and get it ready for the summer? No. Did I change the oil in my snow blower? Oh yeah.
Some people might think I'm nuts to behave this way. But don't you love it when events prove that you are right and everyone else is wrong? That's what happened to me this morning. To be specific, here's what greeted me when I stepped out of the house:
And here's what I saw out my bedroom window. It's more picturesque than what I saw in my driveway, though admittedly, snow-covered trees lose some of their charm come April 23:
Some people might think I'm nuts to behave this way. But don't you love it when events prove that you are right and everyone else is wrong? That's what happened to me this morning. To be specific, here's what greeted me when I stepped out of the house:
And here's what I saw out my bedroom window. It's more picturesque than what I saw in my driveway, though admittedly, snow-covered trees lose some of their charm come April 23:
4/20/2012
Bone researchers gear up with Lego Mindstorms
I'll admit it: I own a Meccano set. And despite my rapidly advancing years, I have no intention to give it up. Pretty sad, right?
Mind you, I've always thought it would be cool to build something useful with it — which is probably my way of rationalizing why I keep the damn thing.
That said, I've just stumbled on a video that shows how a building toy can, in fact, help create something useful — something that may ultimately aid humanity. The toy in this case isn't Meccano, but its 21st century equivalent: Lego MindStorms. Check it out:
Maybe I'll hold on to my Meccano set just a little bit longer. Or maybe I should get with the program, pick up Lego Mindstorms, and start, well, programming. :-)
Mind you, I've always thought it would be cool to build something useful with it — which is probably my way of rationalizing why I keep the damn thing.
That said, I've just stumbled on a video that shows how a building toy can, in fact, help create something useful — something that may ultimately aid humanity. The toy in this case isn't Meccano, but its 21st century equivalent: Lego MindStorms. Check it out:
Maybe I'll hold on to my Meccano set just a little bit longer. Or maybe I should get with the program, pick up Lego Mindstorms, and start, well, programming. :-)
4/11/2012
New video: The making of the QNX concept car
You've seen the finished product in all its infotainment glory. Now look at what went into making the concept car that took home a Best of CES award:
And in case you haven't seen the finished product, check out this video from CNET's Antuan Goodwind. It touches on all of the car's salient features, including one-touch smartphone pairing, backseat entertainment, video streaming, rich app support, ultra HD voice technology, and, last but not least, the reconfigurable digital instrument cluster:
And in case you haven't seen the finished product, check out this video from CNET's Antuan Goodwind. It touches on all of the car's salient features, including one-touch smartphone pairing, backseat entertainment, video streaming, rich app support, ultra HD voice technology, and, last but not least, the reconfigurable digital instrument cluster:
4/02/2012
Qt Commercial 4.8.1 comes to QNX Neutrino RTOS
 |
| QNX patient-monitoring demo equipped with a Qt-based UI. |
According to blog's author, Tuukka Turunen (cool name, that), "Developers looking to develop their products on QNX with Qt Commercial can rest assured that Digia... supports their project with a full support and services team." This is welcome news for the many developers who'd like to use Qt and the QNX Neutrino RTOS together in a commercial device or application.
If you're new to Qt, it's a popular framework for writing applications and graphical user interfaces. It's also cross-platform: You can write your applications once and deploy them across multiple desktop and embedded operating systems, without having to rewrite your source code. This "write once, deploy across" feature helps explain why a number of QNX customers — particularly those in the medical industry — have asked for Qt Commercial support.
In case you're wondering, Qt Commercial is a, well, commercial version of Qt. :-) It's available from Digia, a Finnish company that offers licensing, support, and services to companies who wish to Qt in commercial applications, on either desktop or embedded platforms.
If you visit here often, you may have already seen the QNX patient-monitoring demo, which sports a user interface built with Qt. But if you haven't, check out this video filmed at last year's Embedded World Conference in Nuremburg. Among other things, the video showcases some nifty BlackBerry PlayBook integration:
Any chance you'll be in Moscow on April 19? If so, you can meet up with Digia at QNX Russia 2012, the largest event for the Russian QNX community.
Subscribe to:
Posts (Atom)