|
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 ]
|