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
 



December 2002

Products / Services

 
   
 

Products

 
   
 

 

 
   
 

Custom Services

 
   
 

 

 
 

Customer Spotlight

 
   
 

"Their support has been phenomenal. They helped us get a handle on the upgrade process when we needed guidance. Their technical lead has been here more than once during the upgrade, and to me nothing demonstrates a vendor's dedication and determination like their top technical guy coming in at eight in the morning and leaving at nine at night just to fix your problems." 

Guy Yeager, Raytheon JSOW/GEU
Principal Software Engineer
Software Team Lead

 
   
     
Inside this Issue

 

December 10, 2002

BAE SYSTEMS & DDC-I Join Forces on ARINC-653 Operating System for Safety-Critical Applications

BAE SYSTEMS Controls, a leader in ARINC-653-compliant technology for real-time operating systems, and DDC-I, a provider of tools and services for embedded systems, will jointly develop a platform for writing safety-critical software. The agreement calls for the creation of SCORE-653, combining BAE SYSTEMS’ CsLEOS™ Real-time Operating System (RTOS) with the DDC-I SCORE® (Safety-Critical Object-oriented Real-time Embedded) multi-language development environment.

The integration combines a development environment and an ARINC-653-compliant RTOS, both designed for use in high-integrity embedded systems. SCORE’s multi-language support will allow the Ada and C programming languages to be used in application development. The combination of Ada’s reliability, provided through strong typing and rigorous checks, and the built–in safety features of the CsLEOS™ RTOS provide an ideal platform for development of software for safety-critical uses.

The new environment generates PowerPC cross applications and is supported on Solaris and Windows NT. It also will encompass multi-language compilers, a graphical user interface, and multi-language debugger support.

"With more than 50 years of aircraft flight control experience behind it, our CsLEOS™ operating system is an ideal commercial, off-the-shelf solution to many safety-critical systems requirements," said James Scanlon, president of BAE SYSTEMS Controls. "We are pleased to team with DDC-I, a company respected for its work in embedded systems, to offer customers easier access to this important technology."

DDC-I is seeing increasing demands for software solutions that offer reliable time and space partitioning. "The ARINC-653 standard defines operating systems that meet these requirement," said Dr. Ole Oest, president and CEO of DDC-I Inc. "SCORE-653 will give our customers a well-integrated tool set to enable the development of highly reliable, DO-178B Level A-certifiable applications."

Designed from the beginning to implement ARINC-653 brick-wall partitioning and to be certifiable to the highest FAA DO-178B safety level, the CsLEOS™ RTOS ensures that safety-critical functions are protected from other processes running on the same hardware. This structure also makes is possible to add, revise, and test system functions without recertifying the entire application.

The first development environment to offer multi-language, multi-target, and multi-host capabilities based on non-proprietary open-system standards, SCORE® addresses the increasing need among project developers to create and combine reusable software components–often written in different languages such as Ada and C – targeting different microprocessors and created on different development platforms.

About BAE SYSTEMS:

BAE SYSTEMS is a systems company, innovating for a safer world. BAE SYSTEMS employs nearly 100,000 people including joint ventures, and has annual sales of around $18 billion. The company offers a global capability in air, sea, land, and space, with a world-class prime contracting ability supported by a range of key skills. BAE SYSTEMS designs, manufactures, and supports military aircraft, surface ships, submarines, space systems, radar, avionics, communications, electronics, guided weapon systems and a range of other defense products. BAE SYSTEMS is dedicated to making the intelligent connections needed to deliver innovative solutions.

BAE SYSTEMS North America is a high-technology U.S. company employing more than 22,000 Americans who live and work in 30 states and Washington, D.C. The company is dedicated to solving its customers’ needs with highly innovative and leading-edge solutions across the defense electronics, systems, information technology, and services arenas.

BAE SYSTEMS Controls, an operating unit of BAE SYSTEMS North America, is a leading supplier and integrator of electronic flight and engine control systems for defense and commercial aircraft and launch vehicle applications. It also provides integrated avionics for aircraft applications and complete unmanned aerial vehicle systems and is a leader in electronic controls for the locomotive industry and the emerging heavy-duty hybrid-electric vehicle market. Controls operates facilities in Johnson City, New York; Santa Monica and Ontario, California; Fort Wayne, Indiana; and Redmond, Washington.

About DDC-I:

DDC-I is a global supplier of software development tools, custom software development services, and legacy software system modernization. DDC-I’s customer base is an impressive "who’s who" list in the commercial, military, aerospace, and safety-critical industries. Tools include compiler systems and run-time systems for Ada, JOVIAL, C, and C++ applications development. For more information regarding DDC-I products, contact DDC-I at 400 North Fifth Street, Phoenix, Arizona 85004; phone (602) 275-7172; fax (602) 252-6054; e-mail sales@ddci.com; or visit www.ddci.com. In Europe, contact DDC-I A/S at Gammel Lundtoftevej 1B, DK-2800 Lyngby, Denmark; phone +4545 871144; fax +4545 872217; e-mail sales@ddci.dk; or visit www.ddci.dk.

For further information, please contact:

Larry Stone, BAE SYSTEMS Controls

Tel: 607-770-3944 Mobile: 607-761-9553 lawrence.w.stone@baesystems.com

Jennifer Sanchez, DDC-I Inc.

Tel: 602-275-7172 ext. 201 jc@ddci.com

[ Back to Top ]

Positive Deviants

Typically change agents look outside the organization to see so-called "best practices." Maybe we should be following the example of Save the Children that tackled the malnutrition problem in Vietnam by looking inside to find healthy children.

By Linda Rising

There are many things I like about searching for positive deviants. First of all, the Save the Children story is a great one. Second, it makes me stop and think whenever I want to try to "improve" an organization. In the old days, I would, usually at the behest of a high-level manager, research current "best practices" and then spearhead a task force to "make it happen." After all, if it works for <name your favorite big organization here>, it should work for us, right?

By finding models for change inside the organization, you are getting rid of the traditional organizational development model where you and some outside consultants go in and focus on a community’s deficits. You are the expert and the people involved in the actual work don’t know anything. The positive deviant model says, "We’re not the expert, we don’t know anything. Within your community, you have the answers, so let’s understand together what they are."

Let’s start with the story—it’s not a software tale at all but one that should concern us. It’s about malnourished children in Vietnam and a guy named Jerry Sternin and his wife, Monique. They were part of the Save the Children organization responding to a request from the Vietnamese government. And, here’s something they shared with software projects, they were given an impossible task—nearly half the children in Vietnam were malnourished—and a severe deadline—they had six months to produce results.

The problem of malnutrition is pretty well understood. It’s the result of ignorance, poverty, poor sanitation, faulty food-distribution, and cultural influences. These are tough problems to solve on any level, but impossible to treat in six months. The typical approach is to bring in some engineers and nutritionists with clipboards. They institute a few radical changes, things appear superficially better, and then the experts leave. Since there has been no real change, the experts take their expertise and their good ideas with them and it isn’t long before things are just like they were—maybe worse!

In contrast, here’s a step-by-step outline of the method of positive deviants:

1. Never assume you have the answer.

The Sternins didn’t know a great deal about Vietnam but they believed that the only way to solve the problem was to discover the solution within the Vietnamese villages. They were ready to listen, not to talk. They were ready to learn, not to prescribe. They were ready to find some children who were not malnourished and help others learn from their success.

2. It’s not a cocktail party.

In many organizational change texts, the idea of mixing across departments is encouraged. When identifying positive deviants, the opposite is used. The solutions you find will most likely be community-specific. You’re not trying to brainstorm creative ideas—you’re trying to identify what works. If people can’t identify with the deviants, they won’t adopt the solution, even if it has a proven track record. Stay within the community while you look for solutions.

3. Help them do it themselves.

It’s hard for us to follow this one! I lead retrospectives for companies and the challenge is to allow the teams to develop their own solutions. Since I’m being paid to lead the exercise, many managers want me to simply apply the proper band-aid to each difficulty as it arises. It would save time! But would it? It’s been my experience that when we are handed a solution, it won’t work. When we "own" that solution, because we discover it ourselves, we are much more likely to see it through. That’s exactly the message here. There is research to support this. Allow the community to examine the behavior of the positive deviants. Help them ask questions. Help them understand the deviant behavior. Support their observations with research but let them draw their own conclusions. This takes time but will produce the support you need. Respect and appreciation for local intelligence is required.

The Sternins started with 4 villages. They asked women if there were any children in poor families who were well nourished. The women knew who those children were. The next step was to discover what the families of those well-nourished children were doing that was different from the rest.

4. Learn the culture.

You can’t identify unusual behavior unless you understand typical behavior for the community. Find out what most people do. Ask questions to bring out assumed conventions.

Most Vietnamese communities regarded certain foods as low-class, even though the foods were nutritious. Mothers in the villages did not actively encourage eating. They believed that it wasn’t healthy to feed children with diarrhea.

5. Analyze deviant behavior.

As you learn how the community behaves, the behavior of deviants will surface. It will also become clear that the deviants have found a better way. The results will prove it. The people who need to change can see how to do it if you help them. The people within the community won’t feel that an outside solution has been imposed on them. They will discover the new way themselves.

In the Vietnamese villages the deviant mothers used alternative sources of food, some that was considered low-class. They fed their children even while the children had diarrhea, feeding children more frequently; and making sure that the children actually ate, rather than hoping that the children would take it upon themselves to eat.

6. Allow the community to adopt the deviant behavior on their own terms.

Don’t simply tell the community, "OK, guys, here it is. This is the answer to your problem. Make it happen!" You don’t want to solve a problem; you want to change behavior. Enable a learning environment where people can discover the deviant behavior.

Sternin makes a point of emphasizing the distinction: Don't teach new knowledge—encourage new behavior. Let the people who have discovered the deviations spread the word. Don't require adherence to the new practices, but do offer incentives for it.

In Vietnam, a health volunteer would invite 8 to 10 mothers into her home for medicinal-food training. As a price of entry, the mothers were required to bring a contribution of shrimp, crabs, and sweet-potato greens. They would use the ingredients to cook a meal for the group. After a couple of weeks, most of the group would continue to gather shrimp and greens, and their children would recover. Mothers could re-enroll and go through the two-week process again, over and over, until their children recovered and the behavior became habit.

7. Measure success and share the results.

When you share success, others will be curious. Learn from working with diverse groups and see how they have changed. This retrospective process is always useful and is a "best practice" for software development. To avoid making the same mistakes over and over and to learn from what worked well, take time for reflection to gather lessons learned and share those across the organization.
http://www.ddci.com/news_vol3num5.shtml#Postmortems

Sternin reports, "We saw malnutrition drop 65% to 85% throughout the villages in a two-year period. The Harvard School of Public Health came to the four original villages and did an independent study. They found that children who hadn't even been born when we left the villages were at the same enhanced nutritional levels as the ones who benefited from the program when we were there. That means that the behavior sticks."

8. Repeat.

Once the group has learned from the positive deviants, go back and repeat the process. It’s likely that other positive deviants will have created new solutions and the group can continue to learn. This is the goal of continuous improvement that has long been held up for software development without much real guidance as to how it can be achieved.

Sternin took his positive-deviance program to a total of 14 Vietnamese villages after succeeding in the initial 4. As the program grew, it uncovered new solutions in new localities: sesame seeds, peanuts, snails. The answers were never quite the same, but the process remained the same: Discover original local answers to the problem, and then give everyone access to the secrets.

The most powerful application of this final step was Sternin’s idea of a "living university." The 14 villages became a social lab. People could visit these villages and then return to their own villages and implement ideas they had learned. They could return to learn more. They could build on this success, as their home villages became positive deviants for others. The program ultimately reached 2.2 million Vietnamese in 265 villages.

Over the past decade, positive deviance has been applied to the problem of malnutrition in more than 20 countries through Save the Children. Other non-governmental organizations have applied it in many countries as well, including Bangladesh, Bhutan, Bolivia, Cambodia, Egypt, Ethiopia, Haiti, Myanmar, Nepal, and Sri Lanka.

News of Sternin's work in Vietnam spread rapidly among a variety of non-governmental organizations. Positive deviance is now being applied around the world to change behavior in a variety of other social and organizational situations, such as the spread of AIDS in the Third World and ethnic conflicts in Africa.

Let’s hear a business story. A successful pharmaceutical company had one unit that far outsold all of the other groups. The company believed that the more sales reps you had and the more calls you made on customers, the more you would sell but the positive deviants had fewer salespeople and made fewer calls. By applying the methods described in this article, they found that the successful reps were spending more time with individual doctors, educating them on the benefits and the uses of the products that they sold.

Steven Miller, Managing Director of Shell Oil Products Business Committee: Top-down strategies don’t win many ball games today. We need a different definition of strategy and a different way to generate it. The top can’t possibly have all the answers. The leaders provide the vision and are the context setters but the actual solutions—how best to meet the challenges—have to be made by the people closest to the action.

Barbara Waugh, Worldwide Change Manager for Hewlett-Packard Laboratories: The 60s way of doing things was to dig into a complicated problem, pick out the worst elements, and go after them. Today, I take the opposite approach. I seek out the positive deviants and support them. Give them resources and visibility.

Here’s a brief comparison of positive deviance with traditional organizational development:

Asset model vs. a deficit model. Look for what’s right instead of what’s wrong. It puts you in a completely different frame of mind.

Based on indigenous wisdom within the system vs. expert opinion from the outside. You’re the experts. We’re not coming in to tell you how to do your job.

Cheap vs. expensive.

Goes with the flow vs. disrupting the status quo.

Finds those who are successful and what they are doing differently vs. finding out what’s wrong and trying to fix it.

Stirs up less resistance because we’re learning from our colleagues vs. outside experts and new ideas from the outside.

Produces change that lasts vs. change that doesn’t last.

The biggest benefit comes at a personal level, as one villager told the Sternins, "Let us tell you about the changes in our lives. We were like seeds locked up in a dark place, and now we have found the light." http://www.savethechildren.com

References

Dorsey, D., "Positive Deviant," Fast Company, December 2000.

Pascale, R.T., M. Millemann, and L. Gioja, Surfing the Edge of Chaos, Crown Business, 2000.

Sternin, J. "The Power of Positive Deviancy," Harvard Business Review, January-February 2000.

Waugh, B. with M. Silk Forrest, The Soul in the Computer, Inner Ocean, 2001.

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. She is currently writing a book with Mary Lynn Manns: Introducing Patterns (or any Innovation) into Organizations, to appear in Fall 2002. 

[ Back to Top ]

On the Front Lines

Alex Polmans
Senior Software Engineer
DDC-I, Inc.

 

Introducing Alex Polmans, Senior Software Engineer and DACS Assistant Product Champ. In his role as Assistant Product Champ for the DACS (DDC-I Ada Compiler System) product line, Alex has the responsibility of "front-liner" support issues for U.S. based DACS customers. Alex was recently chosen for this position based on his background and experience with the product. He worked in South Africa for over a decade using DACS products.

Additionally, Alex has experience with DDC-I’s SCORE product line, working closely with the run-time system and debug monitor. He also has specialty skills in object oriented analysis and design in the UML and Schlaer-Mellor methods, documentation of software to 2167A and 498 standards, and UCC’s interfacing to hardware devices.

Born in Durban, South Africa, Alex holds a B Sc Engineering (Electronics) from The University of Natal, South Africa, and a B Sc Honors (Computer Science) from the University of South Africa. He worked for 12 years during 1975 - 1987 as the engineer in charge of Digital Switching Telephone Exchanges for the Natal Province in South Africa. Then from 1987 - 2001 he did real time embedded Command and Control, and Navigation Naval systems work for African Defence Systems (Part of French Thales group) in South Africa, ending up as a Senior Software Specialist in the group.

A DDC-I employee since September 2001, Alex moved to Scottsdale, Arizona with his wife Linda, his son Richard and his daughter Kelly. He enjoys photography & audio mixing.

For more information on Front Liners and DDC-I's organizational structure click here.

[ Back to Top ]

3rd Party Update

BAE SYSTEMS Controls
600 Main Street Room 786
Johnson City, NY 13790
(607) 770-3582
(607) 770-2954 (Fax)

William Barnes
william.g.barnes@baesystems.com

The CsLEOS™ RTOS
The CsLEOS RTOS is the only commercial, off-the-shelf RTOS offered by a safety-critical systems company. Designed from the outset to implement ARINC-653 brick-wall partitioning and to be certifiable to the highest FAA DO-178B safety level, the CsLEOS RTOS ensures that safety-critical functions are protected from other processes running on the same hardware.

The architecture also makes it possible to add, revise, and test system functions without re-certifying the entire application.

The RTOS's ARINC 653-compliant applications programming interface is a true open system offering users the ability to develop applications software to a standard set of interfaces. This ensures ease of use and the most efficient use of development resources.

The CsLEOS RTOS is available now in a flight worthy version. A second product release in the fourth quarter of 2002 will be certifiable to DO-178B, Level A. (D0-178B, developed by RTCA Inc., a nonprofit company in Washington, D.C., is the international standard for certifying software used in safety-critical airborne systems.)

CsLEOS™ RTOS has pre-configured Board Support Packages (BSPs) for a wide range of PowerPC target boards. The CsLEOS™ RTOS BSPs contain all the required code for initializing and utilizing all the board specific hardware required by the kernel.

[ Back to Top ]

Tech Talk:

Memory Mapped I/O in 80x86 Real Address Mode

By Thomas Hansen

Peripheral devices are normally wired to the 80x86 I/O address space, and are thus not memory mapped. However, should you come across a device which is indeed memory mapped, the following discussion illustrates how to access such a device in Real Address Mode (or just Real Mode).

The Real Mode variants of DACS-80x86 support 8086 and 80186, which offer a one megabyte address space. This space is segmented and it is addressed using a segment and an offset, both 16 bits wide. The notation used is <segment>:<offset>

The physical address is obtained as follows:

<Physical address> = <segment> * 10h + <offset>

E.g. the segmented address 2400h:BF00h has the physical address 2400h*10h + BF00h = 24000h + BF00h = 2FF00h

Note, that a physical address can be obtained using a variety of combinations. The above, for example, can also be obtained with 2300h:CF00h (= 23000h + CF00h = 2FF00h).

If you have a device located at a physical address, say B0000h, with a couple of registers:

Status Register B0000h
Transmit B0001h
Receive B0002h

It would be obvious to choose B000h as the segment portion along with the offsets 0, 2 and 4 respectively:

Device Register

Physical Address

Segment

Offset

Status

B0000h

B000h

0h

Transmit

B0001h

B000h

1h

Receive

B0002h

B000h

2h

A simple Ada declaration for this device could look like the following:

with system; use system;
procedure mem_map_io is

   type device_type is record
            status   : system.byte;
            transmit : system.byte;
            receive  : system.byte;
      end record;

   for device_type use record    -- counting the bits
                                    from base address
            status   at 0 range 0..7;  -- first byte
            transmit at 0 range 8..15; -- second byte
            receive  at 0 range 16..23;-- third byte
      end record;

   io_device   : device_type;
      for io_device use at (segment => 16#B000#, 
                          offset => 16#0#);

   bb, cc : system.byte; -- dummies

begin
      if io_device.status = system.byte'(2#01010101#) then
            io_device.transmit := bb; -- Write byte to device
      else
      cc := io_device.receive;     -- Read byte from device
      end if;
end;

Now, in order to prevent the linker from allocating anything else in this memory space you can do one of the following in the linker control file (normally called config.bld_ddci):

A) Do not declare this memory area at all to the linker - if it is not aware of it, it will not use it.
or
B) Declare this memory area as RAM, and declare a dummy segment on its address with the proper length:

RAM: 0B0000h..0B0002

DAT: my_io_segment, 3, 0B0000h

Both schemes are valid, but it may provide better clarity for maintenance purposes to declare the segment. Be careful to select a unique name, which is not used by any other segment in the application.

[ Back to Top ]

 

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