Sin A Car: Safety systems

Showing posts with label Safety systems. Show all posts

Specs for Cars?

Specs for Cars?

Tina Jeffrey As Google Glass , the latest in experimental computer wearables, starts to make its way into the hands of select users, a multi...

11:38:00 AM

<table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPI9R5JTdt8f_Ry79uqtwziv8H7RhE7h4-8jj5Fwvo5eMTii56luXWSbYBYEEXAHARqnLNh1faz_6U6_ZyEEMd7i8pWvCf8zs-ucTDpGkQhgXNcB9BJGaVuH5zZoto6kethLv8bdXLK_w/s1600/paul_leroux_photo_crop_v3_thumb.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPI9R5JTdt8f_Ry79uqtwziv8H7RhE7h4-8jj5Fwvo5eMTii56luXWSbYBYEEXAHARqnLNh1faz_6U6_ZyEEMd7i8pWvCf8zs-ucTDpGkQhgXNcB9BJGaVuH5zZoto6kethLv8bdXLK_w/s1600/paul_leroux_photo_crop_v3_thumb.jpg" /></a></td></tr><tr align="center"><td class="tr-caption">Paul Leroux</td></tr></tbody></table>I don't know about you, but I'm looking forward to the era of self-driving cars. After all, why spend countless hours negotiating rush-hour traffic when the car could do all the work? Just think of all the things you could do instead: read a novel, Facebook with friends, or even watch Babylon 5 re-runs. Unlike Babylon 5, this scenario is no longer a page out of science fiction. It’s coming soon, <a href="http://qnxauto.blogspot.ca/2012/12/volvo-to-ship-self-driving-cars-in-2014.html">faster than many imagine</a>. That said, the story of the self-driving car still has a few unfinished chapters — chapters in which the human driver still has an important role to play. Yes, that means you. As I’ve discussed in <a href="http://qnxauto.blogspot.ca/2012/07/future-of-self-driving-car-aint-what-it.html">previous posts</a>, the fully autonomous car is a work in progress. In fact, some of the technologies that will enable cars to drive themselves (adaptive cruise control, forward collision avoidance, etc.) are already in place. Moreover, research suggests that these technologies can, among other things, <a href="http://qnxauto.blogspot.ca/2012/09/will-adaptive-cruise-control-spell-end.html">improve traffic flow</a> and <a href="http://qnxauto.blogspot.ca/2012/07/will-autonomous-car-tech-save-your-life.html">reduce accidents</a>. But does that mean you will soon be able to sit back, close your eyes, and let the car do everything? Not quite. Evolution, not revolution If you ask me, <a href="http://www.wired.com/opinion/2013/01/forget-the-internet-of-things-here-comes-the-internet-of-cars/">Thilo Koslowski</a> of Gartner hit the bull's eye when he said that self-driving cars will go through three evolutionary phases: from automated to autonomous to unmanned. Until we reach the endpoint, we should pay heed to the words of <a href="http://www.usatoday.com/story/driveon/2013/01/07/audi-toyota-driverless-cars/1815399/">Toyota's Jim Pisz</a>: autonomous does not mean driverless. <table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBaa1fpcHilPB1URKQlSj7PFIlhap3uH5QCcRdRdF8jdydMD4jkys4HOp9TthmsMZLltmaNa5UJd8lLZZXsX3rHCR_M8TNT9_bGPqeYP-IFQ_eZQzyM8020aD65i0yZCXP2cTZItyXfQo/s1600/jet_327_px.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBaa1fpcHilPB1URKQlSj7PFIlhap3uH5QCcRdRdF8jdydMD4jkys4HOp9TthmsMZLltmaNa5UJd8lLZZXsX3rHCR_M8TNT9_bGPqeYP-IFQ_eZQzyM8020aD65i0yZCXP2cTZItyXfQo/s1600/jet_327_px.jpg" /></a></td></tr><tr><td class="tr-caption" style="text-align: left;"><div style="text-align: center;">If planes can do it…</div></td></tr></tbody></table>Some folks hear this and are disappointed. They point to auto-pilot technology in planes and ask why we can’t have driverless cars sooner than later. The argument goes something like this: "It's much harder to fly a plane, yet we have no problem with a computer handling such a complex task. So why not let a computer drive your car?” If only life were so simple. For one thing, automakers will have to make autonomous cars affordable — doable but not easy. They’ll also have to negotiate a variety of legal hurdles. And in any case, driving and flying have less in common than you might think. When you drive, you must remain alert on a continuous basis. Lose your attention for a second, and you stand a good chance of hitting something or somebody. The same doesn't always hold true in flight. When a plane is cruising at 30,000 feet along a proscribed flight path, the pilot can avert his or her attention for 5 seconds and incur little chance of hitting anything. In comparison, a driver who becomes distracted for 5 seconds is hell on wheels. And, of course, auto-pilot doesn’t mean pilot-less. As Ricky Hudi of Audi <a href="http://ces.cnet.com/8301-34438_1-57563376/is-there-a-self-driving-car-in-your-future/">points out</a>, pilots may rely on autopilot, but they still retain full responsibility for flying the plane. So just because your car is on auto-pilot doesn’t mean you can watch YouTube on your tablet. Bummer, I know. An alarming solution <table cellpadding="0" cellspacing="0" class="tr-caption-container" style="float: right; margin-left: 1em; text-align: right;"><tbody><tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCaoqP3HuMqILfVSFL4bX9GJmuArh9U9kSUxgbaGcU8smIRVNunucbYQz7W7Y2mZu2Er8C6G84rf63b0pM6TvUHH0ZOxiInSV4YjZPPgMMF5913uj-YhhrbiY88h5BACN-BcWRedLr-8k/s1600/alarm_glasses_adas.jpg" imageanchor="1" style="clear: right; margin-bottom: 1em; margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCaoqP3HuMqILfVSFL4bX9GJmuArh9U9kSUxgbaGcU8smIRVNunucbYQz7W7Y2mZu2Er8C6G84rf63b0pM6TvUHH0ZOxiInSV4YjZPPgMMF5913uj-YhhrbiY88h5BACN-BcWRedLr-8k/s1600/alarm_glasses_adas.jpg" /></a></td></tr><tr><td class="tr-caption" style="text-align: center;"><div style="font-size: medium; text-align: start;"></div><div style="text-align: center;"><div style="text-align: left;">Source: <a href="http://blog.modernmechanix.com/">Modern Mechanix blog</a> (and yes, that should  read Frankfurt)</div></div><div> </div></td></tr></tbody></table>All of which to say, the driver of an autonomous car will have to remain alert most or all of the time — until, of course, autonomous vehicles become better than humans at handling every potential scenario. Now <a href="http://www.scientificamerican.com/article.cfm?id=autonomous-driverless-car-brain">that could happen</a>, but it will take a while. It seems that someone anticipated this problem in the early 50s when they invented “alarming glasses” — take a gander at the accompanying photo from the August 1951 issue of Modern Mechanix. Scoff if you will, but a kinder and gentler form of this technology is exactly what autonomous cars need. No, I'm not suggesting that scientists find a better way to glue wires to eyelids. But I am saying that, until cars become fully and safely autonomous, drivers will need to pay attention — after all, it’s tempting to drift off when the car is doing all the work. And, indeed, technologies to keep drivers alert <a href="http://www.tobii.com/gaze-interaction/global/Gaze-Interaction-fields-of-use/advanced-driver-assistance/">are already being developed</a>. Pre-warned means prepared Mind you, it isn’t enough to keep the driver alert; the car may also need to issue “pre-warnings” for when the driver needs to take over. For instance, let’s say driving conditions become too challenging for the car’s autonomous mode to handle — these could heavy rain, a street filled with pedestrians, or an area where lane markers are obscured by snow. In that case, the car can’t wait until it can no longer drive itself before alerting the driver, for the simple reason that the driver may simply take too long to assess the situation. The car will need to provide ample warning ahead of time. The more, the better That cars will become autonomous is inevitable. In fact, the more autonomous, the better, as far I'm concerned. Research already suggests that technologies for enabling autonomous driving can, in many cases, do a better job of avoiding accidents and improving traffic flow than human drivers. They also seem to do better at things like parallel parking — a task that has caused more than one student driver to fail a driving test. But does this all mean that, as a driver, I can stop paying attention? Not in the near future. But someday.

Autonomous, not driverless

Paul Leroux I don't know about you, but I'm looking forward to the era of self-driving cars. After all, why spend countless hours ne...

6:34:00 PM

A matter of context: How digital instrument clusters can enhance the driving experience

<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAAw7k-AFoYWzayDLtJZzOI2BN-5wqy3uHeDlk-38VtyE94YLRDtw_l-f2-smhMbXg9z0PqTJPO47ZRMKU9ssjzO2ocny-oj2PaE_MVGtEFP_XVlOF1Ls_2-DolJWxTSiaMu04eAU6lO8/s1600/emil_dautovic_qnx_crop.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="120" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhAAw7k-AFoYWzayDLtJZzOI2BN-5wqy3uHeDlk-38VtyE94YLRDtw_l-f2-smhMbXg9z0PqTJPO47ZRMKU9ssjzO2ocny-oj2PaE_MVGtEFP_XVlOF1Ls_2-DolJWxTSiaMu04eAU6lO8/s400/emil_dautovic_qnx_crop.jpg" width="94" /></a>I always drive a manual, so checking the tachometer in my car’s instrument cluster has become second nature to me. But while I have a personal interest in what my cluster displays, why would a software company like QNX be interested in instrument clusters? After all, most clusters use physical gauges and relatively little software. The answer, of course, is that automakers are starting to migrate to digital instrument clusters, which replace mechanical gauges with virtual instruments rendered on an LCD display. In fact, <a href="http://onqpl.blogspot.ca/2010/11/qnx-drives-digital-instrument-cluster.html">Jaguar</a> and <a href="http://www.qnx.com/news/pr_3655_1.html">Land Rover</a>, who are pioneers in this market, have been shipping QNX-based digital clusters since about 2010. Here, for instance, is a photo of the digital cluster and dash in the latest Range Rover: <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUW458a0Ogxq1FR0jXKPISJNztVDDirRlKnRzWIKwrmyMe2DBgPtlfM4qVVvUP_pfuwOTC_FCJQ69piaG34NDO6nofj3kbJTcUygs9B-KJRxptCjr2ByLswXFveH1hkmS8kWjYt6IcaXE/s1600/range_rover_cluster_575px.jpg" imageanchor="1"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgUW458a0Ogxq1FR0jXKPISJNztVDDirRlKnRzWIKwrmyMe2DBgPtlfM4qVVvUP_pfuwOTC_FCJQ69piaG34NDO6nofj3kbJTcUygs9B-KJRxptCjr2ByLswXFveH1hkmS8kWjYt6IcaXE/s1600/range_rover_cluster_575px.jpg" /></a> So why use a large LCD display instead of mechanical gauges? For one thing, you can attract early adopters who always want the latest tech and who see large 3D displays as cool. But more importantly, a digital cluster can provide an experience that is both personal and adaptive — personal because consumers today want to control the UX (just as they customize their smartphones) and adaptive to help the driver in a variety of traffic situations. Context matters In the latest <a href="http://qnxauto.blogspot.ca/2013/01/its-bentley-guided-tour-of-new-qnx.html">QNX technology concept car</a>, for instance, the digital cluster can re-configure itself to display a 3D rear view camera to help with parking. Saab pursued similar ideas a few years ago with a <a href="http://en.wikipedia.org/wiki/Saab_900#Black_Panel">context-based cluster</a> that avoids loading the driver with too much information during night-time driving. It will be interesting to see who takes this to the next level with an adaptive HMI that takes speed, location, and driving conditions into account. For instance, driving at high speed on a German Autobahn differs immensely from driving at low speed on a busy downtown street with lots of pedestrians and intersections. These two scenarios place different demands on the driver, and a digital cluster could adapt accordingly. On the autobahn, the cluster could increase the size of the speedometer and tachometer to make them easier to see, while hiding other information that isn’t currently needed. (The cluster would, of course, still display any necessary warnings, such as high oil temperature.) In the city, meanwhile, the cluster could replace the tachometer with pedestrian warnings to improve the driver's situational awareness. Also, think of a car that supports both automatic and manual gear-shifting. A driver who prefers automatic might not be interested in a tachometer, whereas a driver who shifts manually will want to see a RPM readout to optimize gear shifting. A digital cluster could accommodate both preferences. For safety’s sake What does it mean from a safety perspective to include a large display and its attendant electronics in the car? A malfunctioning digital cluster can’t directly kill or injure, but it could give false indications that may lead to an accident. That is why automakers will likely have to address ISO 26262 requirements for their digital clusters. So what is ISO 26262? It’s a standard that focuses on functional safety in cars and other types of passenger vehicles, with the goal of avoiding or controlling system failures. It is similar in content and purpose to the IEC 61508 functional safety standard, to which two QNX OS products <a href="http://www.qnx.com/products/neutrino-rtos/index.html">have already been certified</a>. Read our previous posts (<a href="http://qnxauto.blogspot.ca/2012/10/the-iso-26262-functional-safety.html">here</a> and <a href="http://qnxauto.blogspot.se/2013/03/the-isolation-imperative-protecting.html">here</a>) for more information on ISO 26262. Massive arrays When it comes to digital clusters, I’ve only scratched the surface. For instance, cars are becoming massive sensor arrays that generate tons of data. By leveraging this data, reconfigurable clusters could display contextually relevant information, such as highlighting a person in your path, an accident up ahead, or the current speed limit. And from the automaker’s perspective, a digital cluster could help reduce costs by allowing the same hardware to be used across multiple vehicle lines; in many cases, only the graphics would need to be “reskinned.” <hr />Emil Dautovic is an automotive business development manager at QNX Software Systems, where he is responsible for the European automotive market.

A matter of context: How digital instrument clusters can enhance the driving experience

I always drive a manual, so checking the tachometer in my car’s instrument cluster has become second nature to me. But while I have a person...

10:25:00 AM

Enabling drivers to interact safely with applications and services

<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFc-hwr0uh40hWeQvWVf0sZW5bjoB8C_nzfPq9rQV357TDt6Plrd4CSDma_j8WTFRjqnvpJVAoN4NSeEseLzPwiOC1Cu0EVuNNQjWnVXJpDcR-FIYDt4gerWR2bJdfc1p2-a8Q15l-X7g/s1600/scott_pennock.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjFc-hwr0uh40hWeQvWVf0sZW5bjoB8C_nzfPq9rQV357TDt6Plrd4CSDma_j8WTFRjqnvpJVAoN4NSeEseLzPwiOC1Cu0EVuNNQjWnVXJpDcR-FIYDt4gerWR2bJdfc1p2-a8Q15l-X7g/s1600/scott_pennock.jpg" /></a></div>Since February 2011, QNX Software Systems has been leading an <a href="http://www.itu.int/en/ITU-T/focusgroups/distraction/Pages/default.aspx">international standards effort</a> to help drivers interact safely with applications and services. And not just apps on phones, but apps running in the cloud, in roadside infrastructure systems, in the car itself, and other locations. If you jump to the end of this post, you’ll find a list of use cases being targeted by this effort. For now, let’s look at Use Case 2, Scenario A (arbitration of external message), which illustrates how we are working towards a comprehensive framework for managing distraction and workload. Keeping priorities straight In this user scenario, a navigation maneuver is given priority over a social media status update message. The blue call-out boxes indicate where the ITU-T recommendations under development can enable safe interaction between the driver and applications. For instance, ITU-T recommendation G.SAM will define mechanisms for prioritizing navigation, while G.V2A will define the communications interface between the app and the driver-vehicle interface (DVI), and P.UIA will recommend characteristics of the auditory social media message. Remember that the focus here isn't on how to implement social media in the car, but rather, on how best to manage workload and distraction. <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwEfao_hRE7Whfq1IUHA5xT3j7vgYUTfLw1h_H7IEdaa79xI7lXPAJN66pB4mRj-6obIOJG3I6YI93iii6LfpkKccE67x_ROpSX1F5E3cB_16CtqG0VDZrBuVDgd48L_5a54gHezqiW_I/s1600/fg_driver_distraction_usecase2_scenarioa_600px.gif" imageanchor="1"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhwEfao_hRE7Whfq1IUHA5xT3j7vgYUTfLw1h_H7IEdaa79xI7lXPAJN66pB4mRj-6obIOJG3I6YI93iii6LfpkKccE67x_ROpSX1F5E3cB_16CtqG0VDZrBuVDgd48L_5a54gHezqiW_I/s1600/fg_driver_distraction_usecase2_scenarioa_600px.gif" /></a> Giving a navigation maneuver priority over a social media status update message Often, I am asked how this effort differs from the <a href="http://www.mirrorlink.com/">MirrorLink</a> standard being developed by the Car Connectivity Consortium. The simple answer is that MirrorLink addresses only some of the use cases listed below. For instance, the scope of MirrorLink is limited to applications and services running on nomadic devices. Furthermore, adaptation of the driver-vehicle interface and external applications and services in the current MirrorLink solution uses a simple two-state approach, driving or not driving, which limits the ability of the vehicle to control the timing and modality of communications with the driver. Also, MirrorLink doesn’t adequately address arbitration or integration of communications with all external applications and services. In for the long haul At QNX Software Systems, our aim is to: <ol><li>Work with the relevant parties to identify solutions to the problem of technology-related driver distraction and workload. These parties include automotive, telecommunications, and consumer electronics organizations; standards development groups; academia; and government agencies.</li><li>Determine which aspects of the solution should be standardized, then help drive this standardization.</li><li>Align QNX product roadmaps as solutions develop.</li></ol>To be clear, this is a longer term strategy that will take years to realize. Both the standardization process and the time it takes to deploy technology in vehicles must be factored in. Therefore, we are also pursuing shorter term solutions, some of which I hope to cover in future posts. The end of the beginning The first major milestone in this effort was achieved at the closing plenary of the ITU-T Study Group 12 meeting, held on March 28 in Geneva. Here, <a href="http://www.itu.int/en/ITU-T/focusgroups/distraction/Pages/default.aspx">the final report and 4 deliverables</a> of the ITU-T Focus Group on Driver Distraction were approved. There was also approval of a liaison statement communicating these results to a large list of organizations working on this topic. This marks the end of the focus group, but is really just the beginning for QNX and ITU-T efforts in this area. In future posts, I will explore various aspects of this comprehensive strategy. <hr /> Use cases and user scenarios targeted by ITU-T recommendations Use Case 1: Interaction with external application/service    a) Application on nomadic device    b) Application on cloud-based server    c) Downloaded Application    d) Broadcast of roadway information    e) Tethering Use Case 2: Arbitration and integration of external message    a) Arbitration of messages    b) Integration of messages    c) Both arbitration and integration of messages    d) E-call Use Case 3: Negotiation of network Quality of Service (QoS)    a) Application selects network    b) Application suspends interaction    c) Application availability due to roaming Use Case 4: Management of multiple dialogues    a) Opening/closing an application    b) Switching between applications    c) Interaction with background application Use Case 5: Adaptation of DVI (driver-vehicle interface) and external applications/services to driver abilities    a) Driver with disability    b) Dynamically changing driver capabilities    c) Detection of impaired driver state Use Case 6: Adaptation of DVI and external applications/services to roadway situation    a) Driver busy notification    b) Delay of message delivery in demanding driving situation    c) Change message format based on road conditions    d) Interruption of driver interaction Use Case 7: Adaptation of DVI and external applications/services to vehicle status    a) Vehicle enters safe operating condition (e.g., park gear, < 5 m.p.h., etc.)    b) Driver adjusts vehicle controls (e.g., climate control, etc.)    c) Suppression of hazard alert due to safe speed Use Case 8: Adaptation of DVI and external applications/services to local regulations    a) Application blocked    b) Application suspended    c) Interface modality disabled    d) Age restriction    e) Content restriction For details on these use cases, download the <a href="http://www.itu.int/en/ITU-T/focusgroups/distraction/Documents/deliverables/FG%20Distraction%20-%20Report%20on%20Use%20Cases.pdf">FG Distraction Use Cases report</a>.

Enabling drivers to interact safely with applications and services

Since February 2011, QNX Software Systems has been leading an international standards effort to help drivers interact safely with applicati...

9:25:00 AM

Using smartphones to prevent traffic jams

Using smartphones to prevent traffic jams

Paul Leroux Smartphones and driving don’t mix, right? Normally, you would get no argument from me. Driving is the one activity where a half-...

6:04:00 PM

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

<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF70n8XEFXd-WCle6B_N5zb1HOWT6A2287uJL5IptS__jCjo-sMeLzRAv-qrES7Wnj9wEZiA4bLTxtEtJfmSDnchUPzbOIeuufEo685uCHndKAp_EbWo2F-A2ermk7zqXoap_GTGgnSh0/s1600/paul_leroux_photo_crop_v3.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="124" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjF70n8XEFXd-WCle6B_N5zb1HOWT6A2287uJL5IptS__jCjo-sMeLzRAv-qrES7Wnj9wEZiA4bLTxtEtJfmSDnchUPzbOIeuufEo685uCHndKAp_EbWo2F-A2ermk7zqXoap_GTGgnSh0/s400/paul_leroux_photo_crop_v3.jpg" width="87" /></a>Software components can be impolite, if not downright delinquent. For instance, a component might: <ul><li>rob other components of CPU time </li><li>rob other components of file descriptors and other system resources </li><li>access the private memory of other components </li><li>corrupt data shared with other components </li><li>create a deadlock or livelock situation with other components </li></ul> 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 <a href="http://qnxauto.blogspot.ca/2012/10/the-iso-26262-functional-safety.html">ISO 26262 functional safety standard</a> for road vehicles, which defines interference as: <ul>"...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” </ul> 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: <a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqXB2d5X4JJhti1Ph67QQmAb2Hd05LNAa3btIhcr6eHMPDLUjoDoWf3HrMEQxInso0iLhI1sM6G2zXrJpdIu80xyOij0PbeqfEo3Nsyd3K2NHL89TT25InUR9ltqO-w-ddW6vJHC1Yhlw/s1600/isolation_axes.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhqXB2d5X4JJhti1Ph67QQmAb2Hd05LNAa3btIhcr6eHMPDLUjoDoWf3HrMEQxInso0iLhI1sM6G2zXrJpdIu80xyOij0PbeqfEo3Nsyd3K2NHL89TT25InUR9ltqO-w-ddW6vJHC1Yhlw/s1600/isolation_axes.jpg" /></a> 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 "<a href="http://www.qnx.com/download/feature.html?programid=24546">Protecting Software Components from Interference in an ISO 26262 System</a>," and it explores techniques that can help you: <ul><li>implement the component isolation required by ISO 26262</li><li>demonstrate that such isolation has been implemented</li></ul> And while you're at it, check out the other titles in our <a href="http://www.qnx.com/download/group.html?programid=21552&tag=safety">"safe" whitepaper series</a>. 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.

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 othe...

9:40:00 AM

An (info)graphic look at self-driving cars

An (info)graphic look at self-driving cars

If I were in the insurance industry, I'd be following the development of autonomous cars with keen interest. Think about it: all those c...

9:56:00 AM

Sin A Car

Specs for Cars?

Autonomous, not driverless

A matter of context: How digital instrument clusters can enhance the driving experience

Enabling drivers to interact safely with applications and services

Using smartphones to prevent traffic jams

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

An (info)graphic look at self-driving cars

Popular Posts

Blog Archive