|
The Safety Solution … Certified!!!
A Complete Package of Tools & Services for
Developers of Software Where Safety Critical Behavior is Paramount
 Making it’s debut at the upcoming
Software
Technology Conference (Booth #434) in Salt Lake City, UT on
April 28 to May 1, 2003, BAE SYSTEMS Controls, DDC-I and Enea
TekSci join forces to offer the most powerful, proven solution
available for the military/aerospace, high reliable, safety-critical
software community.
Introducing, The Safety Solution ... Certified!!! This team
solution offers a complete package of tools and services for
developers of software where safety-critical behavior is paramount.
The CsLEOS™ RTOS is a commercial, off-the-shelf, real-time operating
system developed by BAE SYSTEMS. It employs brick-wall time and
space partitioning to operate multiple applications independently of
each other, so that if one application experiences a failure, other
applications are unaffected. The CsLEOS™ RTOS is ARINC-653-compliant. Its
programming interface ensures ease of use, and its RTCA/DO-178B,
Level A, certification provides the highest industry reliability
standards for safety-critical use.
Serving the safety-critical industry for over 20 years,
development tools from DDC-I compliment the solution. DDC-I’s
SCORE®, or Safety Critical, Object-oriented Real-time Embedded
toolset includes a multi-language development environment complete
with C, Embedded C++, and Ada compilers, a multi-language debugger,
and a user-friendly graphical user interface.
Support and certification services from Enea TekSci, the largest
and fastest growing independent high-reliability consulting company
in the US, complete the solution by offering knowledgeable software
engineers and full-time Federal Aviation Administration Designated
Engineering Representatives with extensive experience in all phases
of the avionics life cycle.
The result… A reliable, proven & certified solution
for safety-critical software development. Stop by booth #434 at STC
2003 for a personalized demo of this exciting partner solution!
[
Back to Top ]
DDC-I Releases Upgraded JOVIAL Programming Tools
Phoenix, Arizona & Lyngby, Denmark — March
27, 2003 — Continuing to serve customers
writing new JOVIAL code and maintaining legacy code on high-profile
projects including the F-16 Fighting Falcon, DDC-I announces the
availability of an upgrade to the DDC-I JOVIAL Compiler System
(DJCS) with improvements aimed at increasing project efficiency.
First available in 1983, DJCS is a robust and proven product for
the development of real-time embedded applications targeting the
1750A and Z8000 processors. Specific features of this upgrade
include an improved compiler code optimizer, and the system is now
capable of processing applications with larger JOVIAL COMPOOLS, a
section reserved for interprogram communication.
Optimizing code for size and speed, the compiler accepts
MIL-STD-1589C JOVIAL (J73) with no conversion required. Implicit
COMPOOL importation brings in only symbols that are used. The system
also supports 1750A expanded memory address states, and it has
extensive directives for embedded applications. The target
architecture coupled with a highly flexible linker allows user
control of target memory mapping.
The DJCS target assembler
converts target assembly code into linkable object format. The
target embedded systems linker provides extensive flexibility for locating code and data sections.
Using symbolic debug information generated by the compiler, the
system offers source line and screen-oriented debugging of source
and assembly code, using the instruction set simulator or the target
hardware.
Hosted on Sun SPARC®/Solaris, DJCS is a complete solution
containing a compiler, a stand-alone target assembler and embedded
linker, and an X-window based target instruction set simulator.
[
Back to Top ]
DDC-I's Mature TADS-i960 Software Development System
Offers Full Support for Windows NT, 2000, and XP Host Environments
Phoenix, Arizona & Lyngby, Denmark — March 31, 2003 — DDC-I
today announces the addition of support for Windows® based
development platforms for the TADS Ada Development System targeting
the Intel i960 product family. In addition to Windows NT, 2000, and XP
host capabilities, TADS-i960 continues to support the original Sun™
SPARC®, and DEC VAX/VMS host development environments.
"We updated TADS-i960 to enable hosting on the latest versions
of Windows to meet the needs of many of our customers, who are
steadily migrating safety-critical real-time software development to
these increasingly popular enterprise network platforms,"
explains Harold "Bud" Blum, DDC-I Senior Software Engineer
and Product Champion for the TADS-i960 product line.
TADS-i960 offers a mature solution with Ada-specific optimizations
like constraint and overflow check elimination, parameter binding,
data packing, and static aggregates initialization. With
target-specific and classical optimizations tuned for the i960
architecture, five optimization levels permit the proper optimization
strategy at each point in the development cycle. Multiple process
management facilities and on-chip memory management help produce the
lowest possible run-time memory usage on an i960.
"For real-time embedded system developers in aerospace,
avionics, defense, and any other safety-critical industry where
application failure is not an option, TADS is a valuable development
environment, and DDC-I remains committed to ensuring our customers
have quality tools and customized solutions to meet their specific
development requirements," concludes Blum.
[
Back to Top ]
Third Party Update:
Software Certification
By Tony Baghai, Enea TekSci
The DO-178B/ED-12B, published by RTCA, provides guidelines for
the production and design of airborne systems equipment software. It is used
internationally to specify the safety and airworthiness of software for avionics
systems. This guideline provides guidance on design, specifying, developing,
testing and producing and certifying software in safety critical avionics
systems. It describes techniques and methods appropriate to ensure the integrity
and reliability of such software.
Any safety critical embedded product being developed, that contains software,
for use in commercial airplanes will follow a similar process as defined here.
Systems Development
The guidelines for software development
and verification are described for each of six software levels. A, B, C, D, and
E. These are done so to accommodate different criticalities of an environment
which are based on the potential of the software to cause safety-related
failures identified by the systems safety assessment. Level A is used when
anomalous behavior causes catastrophic failure condition, such as loss of the
vehicle. Level E is used when anomalous behavior has no effect on safety and
operational capacity. The level of software category is directly proportional to
the level of activities and effort required to comply with DO178B objectives and
guidance.
Guidelines are provided for all aspects
of the software lifecycle, including in the areas of related systems and
software planning, development activities, verification planning and processes,
configuration management, quality assurance, certification steps and
coordination, and maintenance of software. The guidelines define processes for
software where safety, quality and maintenance are the focus. The processes are
imposed the product is conceived with safety and quality in mind from the on
set, however it does allow for some levels of reverse engineering and
alternative means of meeting the guidance.
The guidelines impose criteria on the
software life-cycle processes to ensure that the development results in a safe
and quality system. The following figure illustrates the basic activities, and
elements of a software life-cycle model, independent from a prescribed software
engineering development method. This model reflects the basic activities of
defining the systems specifications, software requirements and design
specifications, implementation steps, testing, verification and integration.
This is independent of the methodology of software lifecycle, like water fall,
Object Oriented, quick prototyping etc. This process is used to illustrate the
concurrent nature of the activities in the software development process. The
software development activities are the main product-oriented activities and can
be done to some degree concurrently. The other integral processes such as
verification, configuration management, quality assurance and certification
activities, provide software engineering process support that helps ensure the
completeness and quality of the software development activities. A productive
process uses a constructive approach that satisfies the completion criteria of
the integral processes during the software development activities.
Click to view larger image
Contact Enea TekSci at 480-753-9200 or http://www.teksci.com
for the complete white paper describing software certification. It offers
information on Overall Processes & Data Generation as well as Verification
Methodologies.
As the largest independent
safety-critical software consulting company in the U.S., Enea TekSci has over
2,000 person-years of embedded software expertise via RTCA-DO178B: TekSci’s
100+ software engineers and DERs have all contributed to the expertise and
valuable knowledge available through technical seminars. The next DO178B
Certification Training seminar is May 1-2, 2003 in Phoenix Arizona.
For more information, go to http://www.teksci.com/teksci/news_ustraining.asp
or call 480-753-9200.
[
Back to Top ]
Scenarios: Fortune Telling for Organizations
By Linda Rising
How does your organization plan for the future? How do
you know what you will do next quarter or next year? Unfortunately—or
fortunately—no one knows the future. Most of the time, strategies are
"rational" guesswork. Sometimes, we follow the default route—do
what we've always done—plan next year's budget based on the current
year's and hope for the best. Does anyone have a better answer? This
article will explain one way—the scenario approach—developed in part
at Royal Dutch/Shell.
In a nutshell, scenarios employ structured story telling. It's the best
possible kind of brainstorming. It encourages people to bring all
information and any concern to the table and hear anything that anyone
has to say. Surprising results can follow.
Neurophysiologist David H. Ingvar provides experimental evidence that
temporally organized memories—he calls them "memories of the
future,"—act as filters for reality. As we go through life, we
prepare for events by creating stories in our minds. For example, a
prospective employee may rehearse answers to questions expected in an
interview. Even if the rehearsed scenario does not play out exactly, the
mind has built up a set of constructs that facilitate perception and
judgment of what is happening. According to this model we all are
natural-born scenario planners.
To see scenarios in action, let’s go back to South Africa in the
early 1990s. The country was at a turning point. Nelson Mandela had been
released from prison and key anti-apartheid groups had been legalized,
but it was not certain whether a peaceful transition to a democracy
would result. The Mont Fleur scenario exercise (named after the
conference center just outside Cape Town) was held in 1991-92. It
brought together a diverse gathering of twenty-two prominent South
Africans – politicians, activists, academics, and business people,
from the Conservative Party and National Party on the right through to
the African National Congress and Pan Africanist Congress on the left.
The participants were concerned about what might happen in their country
over the decade of 1992-2002. They wanted to understand how to build a
better future for their country.
They created four scenarios they believed were plausible and relevant
to South Africa’s future. Note the names for each scenario—how they
reflect—especially if you’re knowledgeable—the essence of the
scenario.
Ostrich. Negotiated settlement to the crisis in South Africa
is not achieved. The government continues to be nonrepresentative
Lame Duck. A settlement is achieved but the transition is
slow and indecisive
Icarus. Transition is rapid but the new government unwisely
pursues unsustainable, populist economic policies.
Flight of the Flamingos. The government’s policies are
sustainable and the country follows a path of inclusive growth and
democracy.
These scenarios were captured in a widely-distributed report. The
team presented and discussed the scenarios with more than 50 groups,
including political parties, companies, academic institutions, trade
unions, and civic organizations.
The results were subtle but interesting. Even though participants did
not agree on a solution to the country’s problems, they were able to
agree on some aspects of how things "worked," on the complex
nature of the crisis, and on some possible outcomes.
In the midst of turbulence and uncertainty, a credible and optimistic
story makes a strong impact. The Mont Fleur team gave vivid, concise
names to important phenomena that were not widely known, and previously
could be neither discussed nor addressed. They agreed that certain
solutions could not work: armed revolution, continued minority rule
(Ostrich), tightly circumscribed majority rule (Lame Duck), and
socialism (Icarus). Out of this agreement, a feasible and desirable
outcome emerged (Flamingos).
This example clearly shows how scenarios can help us recognize and
adapt to changes in our environment. Scenario planning helps make
choices with an understanding of how things might turn out. Often
scenarios can help people foresee decisions—usually difficult
decisions—that they would otherwise miss or deny.
Scenarios are not predictions. It’s not possible to predict the
future. Rather, creating scenarios helps us learn. Unlike traditional
business forecasting or market research, scenarios uncover alternatives
instead of just extrapolating current trends.
"So," you may ask, "How do you create scenarios?"
The answer is a bit like the one for writing an article. There is a
process but there is also a lot of creativity and flexibility. The first
thing to do is decide what you want to decide. Frame the goal as a
question.
Should we acquire that new business?
Should we build that giant offshore oil-drilling platform?
Should we initiate that new project, even though we’ve never
done anything like that before?
Step two—determine the driving forces—those things that influence
the outcome of events. Usually these forces fall into one of four
categories: Society, Technology, Economics, and Politics.
Here’s an example. [Schwartz] Publishers print massive overruns of
popular "mass-market" paperback books. Bookstores order more
than they can sell, knowing that a few will take off as best sellers.
Those that don’t sell are returned to the publishers who refund their
cost to the bookstores and pulp the books. It’s a wasteful, costly
practice. Here’s the question: Should this business practice continue?
Here are some driving forces.
Society
Continuing population growth—drives a continuing market for
books, especially since people tend to read more as they grow older.
Literacy in America—hard to measure but generally felt to be
declining.
Increasing cultural diversity in America—opens new markets and
changes demographics of old markets.
Technology
Continuous improvement and innovation in electronic media—could
shrink the reading audience or affect book distribution.
Improvements in paper shredding and recycling technologies—could
make it cheaper to shred books.
Economics
Transportation costs—could increase costs of printing and
pulping books.
Transportation costs depend on the cost of oil and on inflation.
Politics
Legislation that allows taxation on publishers’ inventory in
warehouses—adds pressure to destroy unsold books.
Some countries impose import restrictions on American books for
sale.
There is always pressure within any corporation to continue
existing practice, rather than experimenting with new ones.
Publishers have invested in developing and promoting the existing
distribution channels.
Now ask which of these forces are important and which can be ignored?
Restrictions on imports, for example, can probably be ignored unless it’s
plausible that these restrictions might change, in which case, books
returned from bookstores could be profitably shipped to other countries.
Some forces are clearly significant: transportation costs and
declining literacy rates, but their effect may be ambiguous. Declining
literacy rates could mean a shrinking market or a growing market
(compared with hardback books). To learn which is more likely, you will
have to do research.
You may not immediately see any influence from some forces but don’t
rush to discard them. For example, environmental influences may seem
unimportant, but shortages could raise the price of paper. Even a
perceived crisis could lead to public pressure for more efficient
publishing. Farsighted publishers, realizing that more efficient
practices would save them money in the long run, might promote
environmentalism for their own self-interest.
You have little control over driving forces. You can recognize them
and understand their impact. Some driving forces are predetermined
elements and some are critical uncertainties.
Predetermined elements hold no matter what scenario comes to pass.
Here are some hints for identifying predetermined elements.
- Slow-changing phenomena, e.g., growth of population, building
of physical infrastructure, development of resources.
- Constrained situations, e.g., the populations of all industrial
countries are aging.
- In the pipeline, e.g., the size of the teenage population in
the U.S. in 2010 has been determined; all of them have been born
already. They are already in the pipeline. The only uncertainty is
immigration.
- Inevitable collisions, e.g., the American public’s refusal to
allow government to raise taxes while they also refuse to forego
public benefits.
Critical uncertainties are the unknowns. "We know they have to
come from the east, General, but we don’t know if they’re traveling
up the mountain or through the forest. Here’s what we’ll do in
either case." In the 1970s futurists said that oil reserves would
be exhausted by the 1990s. They were right about the predetermined
elements: population growth and the on-going level of energy consumption
at the current prices. There was, however, a critical uncertainty that
few considered: would people be willing to change their habits if the
price of oil rose? They did and that change made a critical difference.
When you’re ready to try scenario planning, gather a team of people
who are aware of the decision to be considered. Team members should have
done their homework. Spend a day developing answers to these questions:
- What are the driving forces?
- What are the predetermined elements—the inevitable?
- What are the critical uncertainties—the unknowns?
- What are some plausible scenarios?
Eventually you will reach a point where ideas are churning. Break for
the evening. Go home. The next morning someone will say, "You know
as I was lying there last night (or in the shower or eating breakfast),
I had an idea for a scenario." Then that person will lay out the
scenario, fairly complete. Then someone else will offer, "And here
is the alternative scenario."
Try to design at least one scenario that frightens people enough to
think—but not so much that they shut down. Consider a shrinking market
or a hostile takeover but not a nuclear war. Look for alternatives that
lead to different choices for the original decision. Look for
alternatives that might make you do something different.
After you’ve identified a collection of scenarios, narrow and
combine them into two or three fully detailed descriptions of what might
happen. Our minds can cope with only two or three possibilities.
Although there is a trap with three: it’s easy to offer a bland
assortment in which one represents the high road, one the low road, and
one the average of the two. To avoid this, keep returning to the
decision, trying to make the paths a bit off-the-wall, avoiding
business-as-usual.
Imagine that you were trying to write the scenarios ten years ago.
What would have been the right scenario, what were the driving forces,
what could you have seen then that you didn’t? Many times we realize
that everything was there—it was missed, not for lack of information,
but as a result of denial and lack of methodology. We didn’t want to
see it and didn’t have a way to force us to see it. A scenario can
help solve that problem.
There’s an almost irresistible temptation to choose one scenario
over the others, "This is the future we believe will take place.
The other futures are interesting but irrelevant, so let’s follow this
scenario." The reason for scenario planning is to help suspend
disbelief in all the futures, so we can think that any of them might
take place. Then we can prepare, even for what we don’t think is going
to happen.
Similarly, sometimes we don’t want to see the positive side.
Hollywood considered the VCR a threat throughout the 1970s and 1980s and
couldn’t see the possibility of new revenues. They didn’t ask,
"What if it doesn’t kill the theater business?" They
considered only the scenario in which the VCR destroyed them. As a
result, they fought and successfully delayed it, losing millions.
To help managers at Shell overcome their disbelief, they role-play
the future of oil prices. One executive plays the Iranians, another the
Kuwaitis. Others play the oil companies or oil ministers of countries.
Someone says, "It is the summer of 1990 and the Iraqis invade
Kuwait. What will happen?" The "Saudi minister" might
say, "I will increase production by 25%." An oil company
representative might say, "I’ll buy that oil, but not at the
price you offer today." By the end of the session, managers
understood the implications of each possible future, because they had
literally rehearsed them.
Leading indicators are small specific signals that might indicate a
given change was coming. Identify leading indicators in advance when
they’re less open to misinterpretation and it’s harder to use your
fears or confidence to influence your judgment about which future is
unfolding. Warning signs can trigger the appropriate behavior for a
given scenario.
Some planners believe the names may be the most important parts of
the scenario. Names give people a language for talking about the future.
A reference to "The boy who cried wolf" or "Johnny
Appleseed" immediately conveys a complex idea. Try to choose a name
for each scenario that condenses the story’s essence into a few words.
When good names are in place, you can say, "This project makes
sense in the ‘Next Wave’ scenario, but we can’t pursue it under
‘Harder Times.’"
How can you tell whether your scenarios were effective? It’s not
whether you got the future right. The real test is whether anyone
changed behavior because he saw the future differently. Did he change
his behavior in the right direction? Did he do the right thing?
Scenarios can open your mind to policies you might not otherwise
consider. At Mont Fleur, people came forward to influence and improve
the world. In an organization, scenarios provide a common vocabulary and
an effective basis for communicating. Using scenarios means rehearsing
the future. By recognizing the leading indicators, you can avoid
surprises, adapt, and act effectively. The result of scenario planning
is not a better picture of the future but better thinking and an ongoing
strategic conversation about the future.
For more information about scenarios:
[Schwartz] Schwartz, P. The Art of the Long View, Doubleday
Currency, 1991.
The Dance of Change: The Challenges to Sustaining Momentum in
Learning Organizations, Peter Senge, Art Kleiner, Charlotte Roberts,
Richard Ross, George Roth, Bryan Smith, Doubleday, 1999.
"How to Build Scenarios," Lawrence Wilkinson, Wired,
October 26.
http://www.wired.com/wired/scenarios/build.html
"Learning from Mont Fleur: Scenarios as a tool for discovering
common ground"
http://www.gbn.org/public/gbnstory/downloads/gbn_mont_fleur.pdf
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 2003.
[
Back to Top ]
|
Click to view larger image
