Site Map
DDC-I, # 1 in Customer Care     · Safety Critical Embedded Software Development
    · Customized Tools & Services Tailored to Fit Your Needs
    · Legacy Software System Modernization
    · Ada Compilers, C Compilers, C++ Compilers, JOVIAL Compilers, FORTRAN Compilers
 



June/July 2005

Products / Services

 
   
 

Products

 
   
 

 

 
   
 

Custom Services

 
   
 

 

 
 

Spotlight

 
   
 

"DDC-I brings over twenty years of experience with safety-critical embedded system software to the Eclipse platform."

Mike Milinkovich,
Executive Director Eclipse Foundation
 

 
   
 

 

 
 

Contact the Editor

 
   
 

DDC-I Online News is published by DDC-I, Inc., 400 N. 5th Street #1050; Phoenix, AZ 85004, Editor: Jennifer Sanchez

Comments and submissions of articles are welcome and should be sent to the editor at the above address or by email to editor@ddci.com.

Copyright 2005, DDC-I, Inc. Permission to copy is prohibited. References to other companies and their products use trademarks are owned by the respective companies and are for reference purposes only.

 

 
   
 

 

 
DDC-I Online News
Inside this Issue

For Immediate Release

DDC-I Joins the Eclipse Foundation

Offers Integrated Solution for Safety Critical Software Developers

June 1, 2005 – Phoenix, AZ – DDC-I, a global leader in safety critical software tools for embedded applications, announced today they have joined the Eclipse Foundation, and will market their SCORE development tools for VxWorks under the Eclipse Integrated Development Environment.

DDC-I joins the Foundation as an Add-in Provider, and is in the process of creating Eclipse-based products optimized for Wind River's VxWorks RTOS. The final product, due to release in Q3, will be an integrated solution which means one GUI / one feel under Workbench, Wind River's Eclipse based development environment.

"The fact that our solution will truly be integrated is what sets us apart from our competitors," states David Mosley, DDC-I Engineering Manager and SCORE® Product Champion. "This new product will offer world-class SCORE compilers & a wide range of third party tools being integrated into Eclipse."

"The goal of Eclipse is to create a universal development platform enabling global enterprises to develop software more efficiently," explains Eclipse Foundation Executive Director Mike Milinkovich. "DDC-I brings over twenty years of experience with safety-critical embedded system software to the Eclipse platform. Their SCORE product's close integration with Eclipse Strategic Developer Wind River's Workbench and VxWorks RTOS offers embedded developers even greater flexibility."

Founded in November 2001 by industry heavyweights IBM, Borland, Red Hat and others -- including Oracle, SAP and Intel -- the Eclipse Foundation's open source development environment is gaining traction in the enterprise market and reaching into embedded systems, where a number of vendors are adopting Eclipse technology.

Dedicated to providing an industry-wide platform for the development of highly integrated tools, the independent Eclipse "ecosystem" is built atop royalty-free technology and universal tool integration, using a plug-in based framework making it easier to create, integrate and utilize software tools. By collaborating and exploiting core integration technology, tool producers like DDC-I and Wind River are leveraging platform reuse and concentrating on core competencies to create new development technology for safety-critical software programmers.

[ Back to Top ]

In The News

What Consumes Most of an Embedded
Developer's Time?

By David Mosley

Software Development Times (Issue 126, May 15, 2005, page 37) reports on a poll from Virtutech taken at the Embedded Systems Conference this year in San Francisco. The survey quizzed developers about the type of tools they used and the time they spend on each. So what software tool or activity consumes most of an embedded developer's time?

Perhaps not too surprisingly the answer is debugging. 34% reported spending more than one-half of their time chasing software bugs. Another 49% reported they spend one-quarter to one-half of their time in the same pursuit. That is a lot of person-hours spent finding software bugs.

The most common debugging tools used were (in decreasing order) interactive debuggers, in-circuit emulators, and hardware trace capture tools. Most developers still debug mainly on actual or prototype hardware and not on an embedded system emulator.

Given the amount of time and money spent fixing problems, there are huge savings to be realized if the bugs could be avoided in the first place. The first step is to use a language that allows the compilers to find more than the average number of errors. These languages need strong type checks that work across functions and files. The language needs to disallow implicit type conversions, provide unambiguous specifications, hide implementation details, etc., etc. Hmmmm.... I wonder what language does all that?

Regardless of the language, you will still need a humdinger of a symbolic debugger. A good symbolic debugger will be worth its weight in, well a lot more than gold. Companies and developers should purchase software development tools based on the quality of the debugger that's included.

[ Back to Top ]


 

Tech Talk

The Ada Business of Importing and Exporting

By Johan P. Olmütz Nielsen

From its conception, Ada was designed to support interfacing with code originating in other programming languages.

In Ada 83, pragma Interface provided the standardized way of accessing entities originating outside the Ada world. Unfortunately, many aspects of the access was implementation defined and there was no standardized way of making Ada entites accessible outside the Ada world.

These shortcomings were addressed by the introduction of the pragmas Import and Export. Their names and most aspects of them were standardized by Ada 95 to ensure a far better portability across platforms and compiler systems. Using pragma Import and Export, it is possible to write highly portable interfaces to standardized languages such as C (and the C subset of C++) and Fortran. With the Ada 95 standardization of pragma Import and Export, pragma Interface was removed as a language defined pragma.

In spite of this, knowledge about the Ada 83 interface solutions is still relevant. Either when migrating from Ada 83 to Ada 95 or in connection with maintenance of Ada source code which is used in both Ada 83 and 95 applications.

SCORE Ada supports a number of implementation defined interfacing pragmas for compatibility with different Ada 83 dialects. These compatibility pragmas are internally handled as equivalents of pragma Import or Export. The following describe these equivalences.

  1. pragma Interface( assembler_convention, Entity ) is equivalent to
    pragma Import( Assembler, Entity )
    for assembler_convention in { As, Asm86, Asm_Acf, Asm_Noacf, Assembler, Assembly }

     
  2. pragma Interface( Ada, Entity ) is equivalent to
    pragma Import( Ada, Entity )

     
  3. pragma Interface( c_convention, Entity ) is equivalent to
    pragma Import( C, Entity )
    for c_convention in { C, C86, C_Acf, C_Noacf }

     
  4. pragma Interface( convention, Entity )
    pragma Interface_Spelling( Entity, "link_name" ) is equivalent to
    pragma Import( convention, Entity, Link_Name => "link_name" )

     
  5. pragma Interface( convention, Entity )
    pragma Linkage_Name( Entity, "link_name" ) is equivalent to
    pragma Import( convention, Entity, Link_Name => "link_name" )

     
  6. pragma Linkage_Name( Entity, "link_name" ) without a pragma Interface is equivalent to
    pragma Export( Ada, Entity, Link_Name => "link_name" )

     
  7. pragma External_Name( Entity, "link_name" ) is equivalent to
    pragma Export( Ada, Entity, Link_Name => "link_name" )

[ Back to Top ]

Something to Think About

Leave ‘em Laughing

By Linda Rising
risingl@acm.org
www.lindarising.org

I’ve been performing in groups of various kinds since I was in grade school, and, over the years, I can remember countless numbers of directors of those groups giving me an interesting piece of advice that I’ve recently re-discovered in a new form:

Don’t worry about making mistakes. Everyone makes mistakes. Just do the best you can throughout the performance—the most important part, the part the audience will remember, is the closing phrase/measure/chord. That must be perfect! Watch and listen and make sure to do your absolute best at the end!

The first time I heard this, I thought the teacher was just trying to get a bunch of wiggly kids to stand still and pay attention for the whole piece. Surely, the ending, a small part of the entire performance, couldn’t have that much impact! It was important, sure, but was it that important?

As I grew older and began to take on the role of director, I began to see the power of a good ending. Everyone felt better if the last phrase/measure/chord was truly memorable. There was definitely a feeling in the group that the performance had been good. It was as though we had quickly forgotten the flubs and missed entrances because the ending was so superb.

The audiences seemed to feel that way, too. Comments were: "That last phrase was heavenly!" "When you sang that last measure, I got shivers down my spine!" "What a powerful sound at the very end! I can still hear it!"

Then I moved on to teaching and training and giving keynote speeches and it seemed that even though no music was involved that the same phenomenon was occurring. The comments from people in the audience or class or training session were more about what happened at the last than anything else (even if I had thought it was all pretty good!). I chalked it up to the power of short-term memory!

I’ve been reading a new book by Barry Schwartz The Paradox of Choice (HarperCollins Publishers Inc., 2004). One of the many interesting things I’ve learned from this book is that we evaluate past experiences on the basis of how (good or bad) they felt at their "peak" and how they felt at the end.

Nobel-prize winning psychologist, Daniel Kahneman, and his colleagues have shown that what we remember about past experiences is almost entirely determined by these two things: how the experience felt when it was at its peak and how it felt when it ended.

Think about that! When people evaluate past experience, they only recall two things: how it felt at the peak and whether it got better or worse at the end. As a result, a slight improvement, even an improvement from "intolerable" to "pretty bad," makes the whole experience seem better, and a bad ending makes everything seem worse. This "peak-end" rule is how we summarize the experience and then we rely on that summary to remember how the experience felt. The summary influences our decision about whether to have that experience again. Virtually all other information appears to be discarded, including "total" pleasantness or unpleasantness (whatever that may mean!) and how long the experience lasted. Things like the ratio of pleasure to displeasure during the experience or how long the experience lasted have almost no influence on our memory of it. Our choices of which experiences to repeat do not always maximize total enjoyment or minimize total pain. Here are several interesting studies (just a few of the many that have been done in this area) that illustrate how this works.

Participants in one study were asked to listen to very loud, very unpleasant noises played through headphones. The first noise lasted 8 seconds. The second noise lasted 16 seconds. The first 8 seconds of the second noise were exactly the same as the first noise, and the second 8 seconds, while still loud and unpleasant, were not as loud. Later, participants were told that they would have to listen to one of the noises again, but that they could choose the first or the second noise. The overwhelming majority chose the second. Note that both noises were unpleasant and both had the same "peak" unpleasantness, but the second had a less unpleasant end, and so was remembered as less unpleasant overall than the first.

In another study, volunteers put "a selected finger" in a vise. Each volunteer endured a series of trials, in which the pressure was either kept constant for the whole trial, increased, or decreased. After each trial, the volunteers, having removed their fingers from the vise, were asked to rate the pain. On average, they said—not surprisingly—that it hurt a lot. What was notable, however, was that the volunteers who had been subjected to decreasing pressure reported less pain than when pressure was maintained or increased, even though the same amount of total force that was applied in each trial was the same.

This last report is of a study with "real" impact. Men undergoing diagnostic colonoscopy were asked to report how they felt moment by moment while having the exam, and how they felt when it was over. The first group had a standard colonoscopy. The second group had the standard exam and when the actual examination was finished, the doctor left the instrument in place for a short time. This was unpleasant, but not as bad as the actual exam because the instrument wasn’t moving. In summary, the second group experienced the same moment-by-moment discomfort as the first group, with the addition of somewhat lesser discomfort for 20 seconds more. A short time after the exam, the second group rated their experience as less unpleasant than did the first group. While both groups had the same peak experience, the second group had a milder experience at the end.

Here’s an added twist on this study—over a 5-year period after this exam, patients in the second group were more likely to comply with calls for follow-up colonoscopies than patients in the first group.

I don’t know about you, but I found this last report to be very convincing! I’m old enough to have had two colonoscopies and I don’t remember either of them as pleasurable experiences! The interesting follow-on result shows that a simple addition to the procedure could mean that more patients would have their follow-up check-ups. Since colon cancer, the third most common cause of cancer death among both men and women in the United States, is frequently preventable and highly treatable if detected early, this could mean a savings of both lives and health costs.

Besides validating what my music teachers had told me and my feelings about performances where I was a director, what can we do with this simple but powerful information?

Here’s something that happened to me on a recent whirlwind tour of Europe (11 flight legs and four countries in less than 3 weeks!). From my point of view, I felt that I gave my best "performance" at each stop. I love to travel and I love to see how people in different countries approach problems in software development. If enthusiasm and passion count, I was ‘way ahead as far as my "peak" performance goes. But that "end" part, the last chord, is not always under my control. Sometimes participants have to leave before the official ending of the experience, so I really never get to say a last "Good-bye, it was great to meet you." In one setting, this was the case and, as a result, the ending was weak. By the time I was ready to leave—and in a hurry to catch a train—only a few people were still around and the finale was rushed. This was in contrast to the last chord in another country where participants shared a nice dinner and enjoyable conversation and before everyone left, there was an informal line of participants who shook my hand or gave me a hug and said a last "good-bye." It can’t be an accident, that when I finally got home, I found an invitation from the second company to "come back anytime." Clearly the "end" experience had made a difference!

Great musical compositions have great beginnings, then build to a climax, and have great endings. It seems to me after having read the research, that this is no accident. Since we have evolved (wouldn’t it be good to know why we do this?) to remember the highlight and the ending for our past experiences, our vacations, our jobs, our customer interactions, and our holiday breaks can all be reduced to a couple of simple elements.

Understanding this can give us considerable influence over the events that we plan for our own lives and for the experiences in our organizations. In the future, ask yourself what the "peak" and "end" will be for the participants for all the experiences you are planning. One of the services I provide in my consulting business is to do retrospectives at the end of projects. I see in every setting how little people remember about what happened over the lifetime of the project—whether it lasted for several years or a few months. The team members remember the end of the project and they have an overall sense of whether it was "good" or "bad"—the peak, but it takes a lot of work to pry those stored memories lose so the team can learn from the past before they begin the next project.

Managers and team leads, remember to celebrate the "end" of each and every project experience. It will impact what team members remember about the quality of that project and if they remember the experience as a "good" one, they will be happier and happier people are more productive and innovative.

I wrote an article about being grateful to those you work with and what a difference just saying thanks can make, not just to the receiver, but also to the giver of those thanks. End experiences with a "thank you" and you will both remember what happened in a more positive light.

Here I am at the end of this article, so I want to leave you laughing—actually I want to leave you thinking! A friend sent me this paraphrase of something Peter Drucker wrote in his book Management first published in 1973.

No organization can depend on genius; the supply is always scarce and unreliable. It is the test of an organization to make ordinary human beings perform better than they seem capable of, to bring out whatever strength there is in its members, and to use each person’s strength to help all the others perform. The purpose of an organization is to enable common people to do uncommon things.

Maybe the "peak-end" tool can help us in this challenging work! Let me know if it works for you!

 

About the Author
http://www.lindarising.org

risingl@acm.org

Linda Rising has a Ph.D. from Arizona State University in the area of object-based design metrics. Her background includes university teaching as well as work in industry in telecommunications, avionics, and strategic weapons systems. She is the author of numerous articles and has published three books: Design Patterns in Communications, The Pattern Almanac 2000, and A Patterns Handbook. Follow this link for information regarding her latest book "Fearless Change: patterns for introducing new ideas".
http://www.cs.unca.edu/~manns/intropatterns.html

[ Back to Top ]

 

   

©2005, DDC-I, Inc., Phoenix, AZ - All Rights Reserved - Webmaster@ddci.com

DDC-I, Inc. -  USA - Phone: (602) 275-7172