Articles by Robert Cravotta

As a former Technical Editor covering Embedded Processing at EDN, Robert has been following and commenting on the embedded processing space since 2001 (see article index). His expertise includes software development and system design using microprocessors, microcontrollers, digital signal processors (DSPs), multiprocessor architectures, processor fabrics, coprocessors, and accelerators, plus embedded cores in FPGAs, SOCs, and ASICs. Robert's embedded engineering background includes 16 years as a Member of the Technical Staff at Boeing and Rockwell International working on path-finding avionics, power and laser control systems, autonomous vehicles, and vision sensing systems.

« Older Entries
Newer Entries »

Is embedded security necessary?

Wednesday, February 16th, 2011 by Robert Cravotta

I recently had an unpleasant experience related to online security issues. Somehow my account information for a large online game had been compromised. The speed in which the automated systems detected that the account had been hacked into and locked it down is a testament to how many compromised accounts this particular service provider handles on a daily basis. Likewise, the account status was restored with equally impressive turn-around time.

What impacted me the most about this experience was realizing that there is obviously at least one way that malicious entities can compromise a password protected system despite significant precautions to prevent such a thing from occurring. Keeping the account name and password secret; employing software to detect and protect against viruses, Trojan horses, or key loggers; as well as ensuring that data between my computer and the service provider is encrypted was not enough to keep the account safe.

The service provider’s efficiency and matter-of-fact approach to handling this situation suggests there are known ways to circumvent the security measures. The service provider offers and suggests using an additional layer of security by using single-use passwords from a device they sell for a few bucks and charge nothing for shipping.

As more embedded systems support online connectivity, the opportunity for someone to break into those systems increases. The motivations for breaking into these systems are myriad. Sometimes, such as in the case of my account that was hacked, there is the opportunity for financial gain. In other cases, there is notoriety for demonstrating that a system has vulnerability. In yet other cases, there may be the desire to cause physical harm, and it is this type of motivation that begs this week’s question.

When I first started working with computers in a professional manner, I found out there were ways to damage equipment through software. The most surprising example involved making a large line printer destroy itself by sending a particular sequence of characters to the printer such that it would cause all of the carriage hammers to repeatedly strike the ribbon at the same time. By spacing the sequence of characters with blank lines, a print job could actually make a printer that weighed several hundred pounds start rocking back and forth. If the printer was permitted to continue this behavior, mechanical parts could be severely damaged.

It is theoretically possible to perform analogous types of things with industrial equipment, and with more systems connected to remote or public networks, the opportunities for such mischief are real. Set top boxes that are attached to televisions are connecting to the network – offering a path for mischief if the designers of the set top box and/or television unintentionally left an opening in the system for someone to exploit.

Is considering the security implications in an embedded design needed? Where is the line between when implementing embedded security is important versus when it is a waste of resources? Are the criteria for when embedded security is needed based on the end device or on the system that such device operates within? Who should be responsible for making that call?

Tags:
Posted in Question of the Week, Security & Encryption | 3 Comments »

How to add color to electronic ink

Tuesday, February 15th, 2011 by Robert Cravotta

Over the past few years, electronic ink has been showing up in an increasing number of end-user products. Approximately ten years ago, there were a couple of competing approaches to implementing electronic ink, but E-Ink’s approach has found the most visible success of moving from the lab and viably existing in production level products, such as e-readers, indicators for USB sticks or batteries, as well as watch, smart card, and retail signage displays.

As a display technology, electronic ink exhibits characteristics that distinguish it from active display technologies. The most visible difference is that electronic ink exhibits the same optical characteristics as the printed page. Electronic ink displays do not require back or front lights; rather, they rely on reflecting ambient light with a minimum of 40% reflectivity. This optical quality contributes to a wider viewing angle (almost 180 degrees), better readability over a larger range of lighting conditions (including direct sunlight), and lower energy consumption because the only energy consumed by the display is to change the state of each pixel. Once an image is built on a display, it will remain there until there is another electrical field applied to the display – no energy is consumed to maintain the image. The switching voltage is designed around +/- 15 V.

However, electronic ink is not ideal for every type of display. The 1 to 10 Hz refresh rate is too slow for video. Until recently, electronic ink displays only supported up to 16 levels of grey scale monochrome text and images. The newest electronic ink displays now support up to 4096 colors (with 4-bit CR bias) along with the 16 levels of grey scale. Interestingly, adding support for color does not fundamentally change the approached used to display monochrome images.

The pigments and the chemistry are exactly the same between monochrome and color display; however, the display structure itself is different. The display is thinner so that it can be closer to a touch sensor to minimize parallax error that can occur based on the thickness of the glass over the display (such as with an LCD). Additionally, the display adds a color filter layer on the display and refines the process for manipulating the particles within each microcapsule.

The positively charged white particles reflect light while the negatively charged black particles absorb light.

The 1.2 mm thick electronic ink display consists of a pixel electrode layer, a layer of microcapsules, and a color filter array (Figure 1). The electrode layer enables the system to attract and repel the charged particles within each of the microcapsules to a resolution that exceeds 200 DPI (dots per inch). Within each microcapsule are positively charged white particles and negatively charged black particles which are all suspended within a clear viscous fluid. When the electrode layer applies a positive or negative electric field near each microcapsule, the charged particles within it move to the front or back of the microcapsule depending on whether it is attracted or repelled from the electrode layer.

When the white particles are at the top of the microcapsule, the ambient light is reflected from the surface of the display. Likewise, when the black particles are at the top of the microcapsule, the ambient light is absorbed. Note that the electrode does not need to align with each microcapsule because the electric field affects the particles within the microcapsule irrespective of the border of the capsule; this means that a microcapsule can have white and black particles at the top of the capsule at the same time (Figure 2). By placing a color filter array over the field of microcapsules, it becomes possible to select which colors are visible by moving the white particles under the appropriate color segments in the filter array. Unlike the microcapsule layer, the electrode layer does need to tightly correlate with the color filter array.

The color filter array consists of a red, green, blue, and white sub-pixel segment at each pixel location. Controlling the absorption or reflection of light at each segment yields 4096 different color combinations.

This display uses an RGBW (Red, Green, Blue, and White) color system that delivers a minimum contrast ratio of 10:1 (Figure 2). For example, to show red, you would bring the white particles forward in the microcapsules under the red segment of the filter array while bringing the black particles forward in the other segments of the array. To present a brighter red color, you can also bring the white particles forward under the white segment of the filter array – however, the color will appear less saturated. To present a black image, the black particles are brought forward under all of the color segments. To present a white image, the white particles are brought forward under all of the color segments because under the RGBW color system, white is the result of all of the colors mixed together.

As electronic ink technology continues to mature and find a home in more applications, I expect that we will see developers take advantage of the fact that these types of displays can be formed into any shape and can be bent without damaging them. The fact that the color displays rely on the same chemistry as the monochrome ones suggests that adding color to a monochrome-based application should not represent a huge barrier to implement. However, the big challenge limiting where electronic ink displays can be used is how to implement the electrode layer such that it still delivers good enough resolution in whatever the final shape or shapes the display must support.

Tags: , , ,
Posted in User Interfaces | No Comments »

Can we reliably predict the winners?

Wednesday, February 9th, 2011 by Robert Cravotta

The Super Bowl played out this weekend and the results were quite predictable – one team won and the other lost. What was less predictable was knowing which of those teams would end up in the win column. Depending on their own set of preferences, insights, and luck, many people “knew” which team would win before the game started, but as the game started and continued toward the final play of the game, many people adjusted their prediction – even against their own wishes – as to the eventual outcome of the game.

Now that this shared experience is passed, I think it appropriate to contemplate how well we can, as individuals and as an industry, reliably predict the success of projects and technologies that we hope for and rely on when designing embedded systems. I think the exercise offers additional value in light of the escalating calls for public organizations to invest more money to accelerate the growth of the right future technologies to move the economy forward. Can we reliably predict which technologies are the correct ones to pour money into (realizing that we would also be choosing which technologies to not put research money into)? In effect, can and should we be choosing the technology winners and losers before they have proven themselves in the market?

Why does it seem that a company, product, or technology gets so much hype just before it falls? Take for example Forbes Company of the Year recipients Monsanto and Pfizer which appeared to be on top of the world when the award was given to them and then almost immediately afterwards faced a cascade of things going horribly wrong. I will only point out that competition in the smartphone market and tablet computing devices has gotten much more interesting in the past few months.

I remember seeing a very interesting television documentary on infomercials called something like “deal or no deal”. I would like to provide a link to it, but I cannot find it, so if you know what I am referring to please share. The big take away for me was one segment where a 30 year veteran in the infomercial world is asked if he knows how to pick the winners. The veteran replied that the success rate in the market is about 10% – meaning that of the products he down selects to and actually brings to market, only 10% are successful. Despite his insights into how the market responds to products, he could not reliably identify which products would be the successful ones – luck and timing still played a huge role in a product’s success.

Luck and timing are critical. Consider that the 1993 Simon predates the iPhone by 14 years and included similar features that made the iPhone stand out when it was launched including a touch screen.Mercata predates Groupon, which Google recently acquired for $2.5 billion, by almost a decade; timing differences with other structures in the market appear to have played a large role in the difference between the two company’s successes. In an almost comical tragedy, the precursor to the steam engine that was perfected by Hero (or Heron) of Alexandria and used in many temples in the ancient world, barely missed the perfect applications at Diolkos – and we had to wait another 1500 years for the steam engine to be reinvented and applied to practical rather than mystical applications.

I meet many people on both sides of the question, should we publicly fund future technologies to accelerate their adoption. My concern is that the track record of anyone reliably predicting the winners is so poor that we may be doing no better than chance – and possibly worse – when we have third party entities direct money that is not their own to projects they think may or should succeed. What do you think – can anyone reliably pick winners well enough to be trusted to do better than chance and allocate huge sums of money to arbitrary winners that still need to stand up to the test of time? What are your favorite stories of snatching failure from the jaws of victory?

Tags:
Posted in Question of the Week | No Comments »

Is assembly language a dead skillset?

Wednesday, February 2nd, 2011 by Robert Cravotta

Compiler technology has improved over the years. So much so that the “wisdom on the street” is that using a compiled language, such as C, is the norm for the overwhelming majority of embedded code that is placed into production systems these days. I have little doubt that most of this sentiment is true, but I suspect the “last mile” challenge for compilers is far from being solved – which prevents compiled languages from completely removing the need for developers that are expert at assembly language programming.

In this case, I think the largest last mile candidate for compilers is managing and allocating memory outside of the processor’s register space. This is a critical distinction because most processors, except the very small and slower ones, do not provide a flat memory space where every memory access possible takes a single clock cycle to complete. The register file, level 1 cache, and tightly coupled memories represent the fastest memory on most processors – and those memories represent the smallest portion of the memory subsystem. The majority of a system’s memory is implemented in slower and less expensive circuits – which when used indiscriminately, can introduce latency and delays when executing program code.

The largest reason for using cache in a system is to hide as much of the latency in the memory accesses as possible so as to be able to keep the processor core from stalling. If there was no time cost for accessing anywhere in memory, there would be no need to use a cache.

I have not seen any standard mechanism in compiled languages to layout and allocate an application’s storage elements into a memory hierarchy. One problem is that such a mechanism would make the code less portable – but maybe we are reaching a point in compiler technology where that type of portability should be segmented away from code portability. Program code could consist of a portable code portion and a target-specific portion that enables a developer to tell a compiler and linker how to organize the entire memory subsystem.

A possible result of this type of separation is the appearance of many more tools that actually help developers focus on the memory architecture and find the optimum way to organize it for a specific application. Additional tools might arise that would enable developers to develop application-specific policies for managing the memory subsystem in the presence of other applications.

The production alternate at this time seems to be systems that either accept the consequences of sub-optimally automated memory allocation or to impose policies that prevent loading applications onto the system that have not been run through a certification process that makes sure each program behaves to some set of memory usage rules. Think of running Flash programs on the iPhone (I think the issue of Flash on these devices is driven more by memory issues – which affect system reliability – than by dislike of another company).

Assembly language programming seems to continue to reign supreme for time sensitive portions of code that rely on using a processor’s specialized circuits in an esoteric fashion and/or rely on an intimate knowledge of how to organize the storage of data within the target’s memory architecture to extract the optimum performance from the system from a time and/or energy perspective. Is this an accurate assessment? Is assembly language programming a dying skillset? Are you still using assembly language programming in your production systems? If so, in what capacity?

Tags:
Posted in Question of the Week, Software Techniques | 43 Comments »

Debugging Stories: Development Tools

Monday, January 31st, 2011 by Robert Cravotta

Anyone that has developed a system has debugging stories. A number of those stories are captured in the responses to a Question-of-the-Week posed a while ago about your favorite debugging anecdote. While collecting the different stories together reveals some worthwhile lessons learned, reading through all of the stories can be time consuming and random as to the type of content in each story. This article, and future others like it, will attempt to consolidate a class of debugging stories together to ease access for you. The rest of this article will focus on the stories and lessons based around issues with the development tools.

In reading through the stories, I am reminded that I worked with a C cross compiler that did not generate the proper code for declaring and initializing float variables. The work around was to avoid initializing the float variable as part of the declaration. The initialization had to be performed as a distinct and separate assignment within the body code. Eventually, within a year of us finding the problem, the company that made the compiler fixed it, but I continued to maintain the code so as to keep the declaration and initialization separate. It felt safer to the whole development team to comment the initialization value with the declaration line and place all of the initialization code at the beginning of the code block.

Two stories identified how the debugger can misrepresent how the actual runtime code executes with and without the debugger in the system. Andrew Coombes shared a story about how the debugger inappropriately assumed when a block of code had the same CRC value as the previously loaded code that it was identical and skipped the process of loading the new code onto the target. The problem was exacerbated by the fact that the debugger did not calculate the CRC correctly. S.B. @ LI shared a story where the debugger was intercepting and correcting the data types in a call structure to an operating system call. This masked the real behavior of the system when the debugger was not active where the data types were not correct.

There were stories about compilers that would allocate data to inappropriate or unavailable memory resources. RSK @ LI shared how he had to use an inline-like function using preprocessor macros to reduce the call depth to avoid overflowing the hardware stack. E.P. @ LI’s story does not specify whether the compiler set the cache size, but the debugged code used a cache block that was one database block large and this inappropriate sizing caused the database application to run excessively slow. R.D @ LI recounts how a compiler was automatically selecting a 14-bit register to store a 16-bit address value, and how adding a NOP in front of the assignment cause the compiler to choose the correct register type to store the value.

I recall hearing many admonishments when I was a junior member of the staff to not turn on the compiler optimizations. I would hear stories about compiler optimizations that did not mix well with processor pipelines that did not include interlocks, and the horrible behaviors that would ensue. J.N. @ LI recounts an experience with a compiler optimization that scheduled some register writes just before a compare so that the system behaved incorrectly.

M.B. @ LI reminds us that even library code that has been used for long periods of time over many projects can include latent problems – especially for functions embedded within libraries, such as newlib in this case. L.W. @ LI’s story tells of when he found a NULL pointer access that had been within a seldom activated conditional with a library call.

I like J.N. @ LI‘s summary – “Different tools have different strengths, which is why you learn to use several and switch off when one isn’t finding the problem. And sometimes one tool gives you a hint that gets you closer, but it takes a different tool (or tools) to get you the rest of the way.”

Please let me know if you find this type of article useful. If so, I will try to do more on the topics that receive large numbers of responses that can be grouped into a smaller set of categories.

Tags:
Posted in Question of the Week, Simulation & Debugging | No Comments »

Is adoption risk real?

Wednesday, January 26th, 2011 by Robert Cravotta

I recently received sales material for solar power panels. According to the literature, I can buy a solar power system that will pay for itself and then continue generating returns for the next 30 to 40 years without the risks associated with investing in stocks. Something about this pitch smacks of overlooking areas of risk when adopting an immature technology. Perhaps I am merely a pessimist on the current state of technology for solar energy, but I think there are significant adoption risks that are analogous to ones that I have had to consider with other technologies.

According to the literature supplied to me: I can buy solar panels with a 30% tax credit and a generous rebate program. Despite the steep discount – these panels will take at least 5 years to reach a breakeven point – and that point assumes I can choose the perfectly sized system for my house. The system comes with a 10 year bumper-to-bumper warranty and a 25 year manufacturer’s warranty. This sounds like a great deal right?

To reach a breakeven point in 5 years, the solar panels need to provide a better than 14.4% annual rate of return on my initial investment. That is quite a healthy rate of return for any static installation to sustain for many years, but I am willing to consider that it might be realistic. I suspect that that rate of return does not include the cost for dismantling, maintaining, and replacing the solar panels – but for this scenario – I am willing to consider those as free activities – no future costs.

I expect that solar power technology will continue to improve each year – in fact, I expect that the rate of improvement of the solar conversion efficiency might mirror Moore’s law about transistor density in some analogous fashion. If this is true – and the organizations providing the rebates and tax credit subsidies are counting on it – solar power technology will be somewhere between four and eight times more efficient in 5 years than a system I would install today.

This scenario strongly reminds me of the opportunities to buy desktop computers in the 1980’s that were future proofed by having the system motherboard be able to accept the next generation processor by merely dropping in the new processor when you wanted it. My experience with those systems was that the extra expense for the extra complexity on the motherboard was not worth the extra cost.

Additionally, there were other things in the system that also changed that made using the motherboard beyond a few years a bad idea – namely, the operating system kept evolving, the device drivers kept evolving, and both of these provided no support for “old and obsolete” peripherals and modules. It was much cheaper, easier, and safer to buy what you needed when you needed it – and then replace it with the next round of available devices when you needed to upgrade.

Am I inappropriately applying this lesson from the past to solar power? According to my lessons learned, I should wait a few more years and realize the resulting improvement in cost and efficiency of solar power – In other words, I might come out ahead if I wait and do nothing today. I believe this is the condition of a classic early adopter. Have you experienced this type of trade-off when choosing components and features for your embedded designs?

Tags: ,
Posted in Energy Management, Question of the Week | 1 Comment »

Are consumer products crossing the line to too cheap?

Wednesday, January 19th, 2011 by Robert Cravotta

I love that the price of so many products continues to fall year in and year out. However, I have recently started to wonder if in some cases the design trade-offs that the development teams for these products are making to lowering the cost to produce them are crossing a quality line. I do not have a lot of data points, but I will share my observations with my office phones as an example that might inspire you to share your experience with some product. Maybe in the aggregate, our stories will uncover whether there really is a trend for razor thin quality margins.

Over the previous ten years, I have relied on three different cordless phone systems. The price for each phone system was progressively lower than the previous phone system and usually provided more functionality than the previous phone. In each case, the phone that I replaced was still working, but there was something else that made replacing the phone worthwhile.

The first cordless phone I purchased was a single-line, 2.4GHz cordless phone. It consisted of a single handset that mounted on a full function base station. I liked that phone a lot. Everything about it was robust – except the fact that it operated in the 2.4GHz band along with so many other devices in and around my office. For example, if someone turned on the microwave, it would cause interference with the phone.

I eventually replaced the 2.4 GHz cordless phone with a dual-line, multi-handset, 5.8 GHz phone systems. That system cost me less than the 2.4 GHz phone and offered additional valuable features. The hand-set was smaller and weighed less. The dual-line capability allowed me to consolidate my phone lines to a single system and the multi-handset feature allowed me to make both phone lines available everywhere in my home office. There were a few features that the new handsets did not provide that I missed from the original phones, but I could use the phones no matter how other devices were being used around the area – so I was happy with the phones.

After a few years of heavy use, the batteries could not hold enough charge. I would regularly switch between handsets during a typical day because the battery in each handset provided less than an hour of talk time. I bought replacement batteries which were better than the original batteries, but only slightly so. With continued use, the new batteries provided longer life (I assume this was because each handset’s state of charge values were slowly adjusting to the new batteries – I’d love if someone could explain or point me to where someone explains why this happened). However, the batteries were only useful for about a year.

At this point, I bought my current cordless phone system which is made by the same manufacturer as the previous two phones. It is a DECT 6.0, dual-line, multi-handset system. It cost less money than either of the other two systems and added a larger database on the base station. However, the phone system exhibits intermittent behavior that I never experienced with my other phones.

Most notably, the communication between the base station and handsets is not always robust. Sometimes a handset will start doing a continuous ringing instead of the normal on/off cycle. Other times the handset will not receive the caller-id that the base station normally sends to it. And other times I will notice a clicking sound that I have not been able to attribute to anything. These examples of lower robustness make me wonder how much the design team shrunk the product’s performance margins to meet a lower price point.

Are these systemic examples of margins that are too small or did I just get unlucky with the phone I received? Because the phone works well most of the time, I suspect it is narrow quality margins that are the culprit – and this made me wonder if other people are noticing similar changes in the robustness of newer products. Do you have a product that you have noticed a change across generations?

Tags:
Posted in Question of the Week, Robust Design | 2 Comments »

Looking at Tesla Touch

Friday, January 14th, 2011 by Robert Cravotta

The team at Disney Research has been working on the Tesla Touch prototype for almost a year. Tesla Touch is a touchscreen feedback technology that relies on the principles of electrovibration to simulate textures on a user’s fingertips. This article expands on the overview of the technology I wrote earlier, and it is based on a recent demonstration meeting at CES that I had with Ivan Poupyrev and Ali Israr, members of the Tesla Touch development team.

The first thing to note is that the Tesla Touch is a prototype; it is not a productized technology just yet. As with any promising technology, there are a number of companies working with the Tesla Touch team to figure out how they might integrate the technology into their upcoming designs. The concept behind the Tesla Touch is based on technology that researchers in the 1950’s were working on to assist blind people. The research fell dormant and the Tesla Touch team has revived it. The technology shows a lot of interesting promise, but I suspect the process of making it robust enough for production designs will uncover a number of use-case challenges (like it probably did for the original research team).

The Tesla Touch controller modulates a periodic electrostatic charge across the touch surface which attracts and repels the electrons in the user’s fingertip towards or away from the touch surface – in effect, varying the friction the user experiences while moving their finger across the surface. Ali has been characterizing the psychophysics of the technology over the last year to understand how people perceive tactile sensations of the varying electrostatic field. Based on my experience with sound bars last week (which I will write about in another article), I suspect the controller for this technology will need to be able to manage a number of usage profiles to accommodate different operating conditions as well as differences between how users perceive the signal it produces.

Ali shared that the threshold to feel the signal was an 8V peak-to-peak modulation; however, the voltage swing on the prototype ranged from 60 to 100 V. The 80 to 100 V signal felt like a comfortable tug on my finger; the 60 to 80 V signal presented a much lighter sensation.Because our meeting was more than a quick demonstration in a booth, I was able to uncover one of the use-case challenges. When I held the unit in my hand, the touch feedback worked great; however, if I left the unit on the table and touched it with only one hand, the touch feedback was nonexistent. This was in part because the prototype is based on the user providing the ground for the system. Ivan mentioned that the technology can work without the user grounding it, but that it requires the system to use larger voltage swings.

In order for the user to feel the feedback, their finger must be in motion. This is consistent with how people experience touch, so there is no disconnect between expectations and what the system can deliver. The expectation that the user will more easily sense the varying friction with lateral movement of their finger is also consistent with observations that the team at Immersion, a mechanical-based haptics company, shared with me when simulating touch feedback on large panels with small motors or piezoelectric strips.

The technology prototype used a capacitive touch screen – demonstrating that the touch sensing and the touch feedback systems can work together. The prototype was modulating the charge on the touch surface at up to a 500 Hz rate which is noticeably higher than the 70Hz rate of the its touch sensor. A use-case challenge for this technology is that it requires a conductive material or substance at the touch surface in order to convey texture feedback to the user. While a 100 V swing is sufficient for a user to sense feedback with their finger, it might not be large enough of a swing to sense it through an optimal stylus. Using gloves will also impair or prevent the user from sensing the feedback.

A fun surprise occurred during one of the demonstration textures. In this case, the display showed a drinking glass. When I rubbed the display away from the drinking glass, the surface was a normal smooth surface. When I rubbed over the surface that showed the drinking glass, I felt a resistance that met my expectation for the glass. I then decided to rub repeated over that area to see if the texture would change and was rewarded with a sound similar to rubbing/cleaning a drinking glass with your finger. Mind you, the sound did not occur when I rubbed the other parts of the display.

The technology is capable of conveying coarse texture transitions, such as from a smooth surface to a rough or heavy surface. It is able to convey a sense of bumps and boundaries through varying the amount of tugging your finger feels on the touch surface. I am not sure when or if it can convey subtle or soft textures – however, there are so many ways to modulate the magnitude, shape, frequency, and repetition or the charge on the plate, that those types of subtle feedbacks may be possible in a production implementation.

I suspect a tight coupling between the visual and touch feedback is an important characteristic for the user to accept the touch feedback from the system. If the touch signal precedes or lags the visual cue, it is disconcerting and confusing. I was able to experience this on the prototype by using two fingers on the display at the same time. The sensing control algorithm only reports back a single touch point, so it would average the position between the two (or more) fingers. This is acceptable in the prototype as it was not a demonstration of a multi-touch system, but it did allow me to receive a feedback on my fingertips that did not match what my fingers were actually “touching” on the display.

There is a good reason why the prototype did not support multi-touch. The feedback implementation applies a single charge across the entire touch surface. That means any and all fingers that are touching the display will (roughly) feel the same thing. This is more of an addressing problem; the system was using a single electrode. It might be possible in later generations to lay out different configurations so that the controller can drive different parts of the display with different signals. At this point, it is a similar constraint to what mechanical feedback systems contend with also. However, one advantage that the Tesla Touch approach has over the mechanical approach is that only the finger touching the display senses the feedback signal. In contrast, the mechanical approach relays the feedback not just to the user’s fingers, but also their other hand which is holding the device.

A final observation involves the impact of applying friction to our fingers in a context we are not used to doing. After playing with the prototype for quite some time, I felt a sensation in my fingertip that took up to an hour to fade away. I suspect my fingertip would feel similarly if I rubbed it on a rough surface for an extended time. I suspect with repeated use over time, my fingertip would develop a mini callous and the sensation would no longer occur.

This technology shows a lot of promise. It offers a feedback approach that includes no moving parts, but it may have a more constrained set of use-cases,versus other types of feedback, where it is able to provide useful feedback to the user.

Tags:
Posted in User Interfaces | No Comments »

What is your most memorable demonstration/test mishap?

Wednesday, January 12th, 2011 by Robert Cravotta

The crush of product and technology demonstrations at CES is over. As an attendee of the show, the vast majority of the product demonstrations I saw seemed to perform as expected. The technology demonstrations on the other hand did not always fare quite so well – but then again – the technology demonstrations were prototypes of possibly useful ways to harness new ideas rather than fully developed and productized devices. Seeing all of these demonstrations at the show reminded me of the prototypes I worked on and some of the spectacular ways that things could go wrong. I suspect that sharing these stories with each other will pass around some valuable (and possibly expensive) lessons learned to the group here.

On the lighter side of the mishap scale, I still like the autonomous robots that Texas Instruments demonstrated last year at ESC San Jose. The demonstration consisted of four small, wheeled robots that would independently roam around the table top. When they bumped into each other, they would politely back away and zoom off in another direction. That is, except for one of the robots which appeared to be a bit pushy and bossy as it would push the other robots around longer before it would back away. In this case, the robots were all running the same software. The difference in behavior had to do with a different sensitivity of the pressure bar that told the robot that it had collided with something (a wall or another robot in this case).

I like this small scale example because it demonstrates that even identical devices can take on significantly different observable behaviors because of small variances in the components that make up the device. It also demonstrates the possible value for closed-loop control systems to be able to access independent or outside reference points so as to be able to calibrate their behavior to some set of norms (how’s that for a follow-up idea on that particular demonstration). I personally would love to see an algorithm that allowed the robots to gradually influence each other’s behavior, but the robots might need more sensors to be able to do that in any meaningful way.

On the more profound side of the mishap scale, my most noteworthy stories involve live testing of fully autonomous vehicles that would maneuver in low orbit space. These tests were quite expensive to perform, so we did not have the luxury of “do-overs”. Especially in failure, we had to learn as much about the system as we could; the post mortem analysis could last months after the live test.

In one case, we had a system that was prepped (loaded with fuel) for a low orbit test; however, the family of transport vehicle we were using had experienced several catastrophic failures over the past year that resulted in the payloads being lost. We put the low-orbit payload system, with the fuel loaded, into storage for a few months while the company responsible for the transport vehicle went through a review and correction process. Eventually we got the go ahead to perform the test. The transport vehicle delivered its payload perfectly; however, when the payload system activated its fuel system, the seals for the fuel lines blew.

In this case, the prototype system had not been designed to store fuel for a period of months. The intended scenario was to load the vehicle with fuel and launch it within days – not months. During the period of time in storage, the corrosive fuel and oxidizer weakened the seals so that they blew when the full pressure of the fuel system was placed upon them during flight. A key takeaway from this experience was to understand the full range of operating and non-operating scenarios that the system might be subjected to – including being subjected to extended storage. In this case, a solution to the problem would be implemented as additional steps and conditions in the test procedures.

My favorite profound failure involves a similar low-orbit vehicle that we designed to succeed when presented with a three-sigma (99.7%) scenario. In this test though, there was a cascade of failures during the delivery to low-orbit phase of the test, which presented us with a nine-sigma scenario. Despite the series of mishaps leading to deployment of the vehicle, the vehicle was almost able to completely compensate for its bad placement – except that it ran out of fuel as it was issuing the final engine commands to put it into the correct location. To the casual observer, the test was an utter failure, but to the people working on that project, the test demonstrated a system that was more robust than we ever thought it could be.

Do you have any demonstration or testing mishaps that you can share? What did you learn from it and how did you change things so that the mishap would not occur again?

Tags:
Posted in Question of the Week, Robust Design | No Comments »

What is your favorite failsafe design?

Wednesday, January 5th, 2011 by Robert Cravotta

We had snow falling for a few hours where I live this week. This is remarkable only to the extent that the last time we had any snow fall was over 21 years ago. The falling snow got me thinking about how most things in our neighborhood, such as cars, roads, houses, and our plumbing, are not subjected to the wonders of snow with any regularity. On days like that, I am thankful that the people who designed most of the things we rely on took into account what impact different extremes, such as hot and cold weather, would have on their design. Designing a system to operate or degrade gracefully in rare operating conditions is a robust design concept that seems to be missing in so many “scientific or technical” television shows.

Designing systems so that they fail in a safe way is an important engineering concept– and it is often invisible to the end user. Developing a failsafe system is an exercise in trading between the consequences and probability of a failure and the cost to mitigate those consequences. There is no single best way to design a failsafe system, but two main tools available to designers are to incorporate interlocks or safeties into the system/or and to implement processes that the user needs to be aware of to mitigate the failure state. Take for example the simple inflatable beach ball; the ones I have seen have such a long list of warnings and disclaimers printed on them that is quite humorous – until you realize that every item printed on that ball probably has a legal case associated with it.

I was completely unaware until a few months ago how a rodent could make an automobile inoperable. Worst, our vehicle became unsteerable while the car was being driven. Fortunately no one got hurt (except the rat that caused the failure). In this case, it looks like the rat got caught in one of the belts in the engine compartment that ultimately made the power steering fail. I was surprised to find out this is actually a common failure when I looked it up on the Internet. I am not aware of a way to design better safety into the vehicle, so we have changed our process when using automobiles. In our case, we do periodic checks of the engine compartment to see if there are any signs of an animal living in there, and we sprinkled peppermint oil around the compartment because we heard that rodents hate the smell.

The ways to make a system failsafe are numerous and I suspect there are a lot of great ideas that have been used over the years. As an example, let me share a memorable failsafe mechanism we implemented on a Space Shuttle Payload I worked on for two years. The payload was going to be actually flying around the Space Shuttle – which means it would be firing engines more than once. This was ground breaking as launching satellites involves firing the engines only once. As a result, we had to go to great lengths to ensure that there could be no way that the engines could misfire – or worse, that the payload could receive a malicious command from the ground to direct the payload into a collision course with the Shuttle. All of the fault tolerant systems and failsafe mechanisms made the design quite complicated. In contrast, the mechanism we implemented to prevent acting on a malicious command was to use a table of random numbers that were loaded onto the payload 30 minutes before the launch and would be known to only two people. Using encryption was not a feasible option at that time because we just did not have the computing power to do it.

Another story of making a system more failsafe involved an X-ray machine. I was never able to confirm if this actually occurred or was a local urban legend, but the lesson is still valid. The model of X-ray machine in question was exposing patients to larger doses of radiation than it was supposed to when the technician pressed the backspace key during a small time window. The short term fix was to send out an order to remove the backspace key from all of the keyboards. The take-away for me was that there are fast, quick, and cheap ways to alleviate a problem that allow you to take the appropriate efforts to find a better way to fix the problem.

Have you ever used a clever approach to making your designs more failsafe? Have you ever run across a product you used that implemented an elegant failsafe mechanism? Have you ever seen a product that you thought of a better way that they could have made the system failsafe or degrade gracefully?

Tags:
Posted in Question of the Week, Robust Design | 1 Comment »

« Older Entries
Newer Entries »