|
|
|
|
||||
| June 2002 | Vol. 3 Issue 6 | |||||
|
|
Inside This Issue
|
|||||
|
****** NEW! ****** |
SCORE®
for OSE By Peder Møller The integration of the SCORE® (Safety-Critical, Object-oriented, Real-time Embedded) suite of programming and testing tools with the OSE RTOS (Real-Time Operating System) from OSE Systems combines a compiler and an RTOS that are both designed for use in high-integrity embedded systems. For the first time, SCORE’s multi-language support provides the application developer the ability to utilize both Ada and C for developing OSE applications. The combination of Ada’s reliability provided through strong typing and rigorous checks and the built-in safety features of the certified OSE RTOS, offers a strong platform for safety-critical software development. The SCORE® IDE with OSE support runs on Solaris and Windows NT platforms and can be used for generating PowerPC cross applications or for generating Solaris native applications running on the OSE SoftKernel. SCORE’s OSE support encompasses both compiler, GUI, and Multi-Language Debugger (MLD) support. The OSE RTOS OSE achieves a high level of safety by restricting interprocess communication to a safe and flexible message passing scheme that avoids the need for shared memory. The efficient encapsulation of OSE processes makes it possible to utilize the OSE MMU support to get full memory protection between processes. Furthermore, the OSE kernel contains extensive internal error checks and a flexible error handling mechanism. The safety guidelines in the OSE documentation helps the application developer to employ OSE for producing highly reliable applications. OSE includes numerous embedded communication products that makes it particularly well suited for distributed systems. An OSE application can for instance be configured with OSE processes running on multiple CPUs and multiple boards communicating through TCP/IP, and the OSE signal communication can be configured so that it is transparent to the OSE processes whether other processes are local or remote. OSE has preconfigured Board Support Packages (BSPs) for a wide range of PowerPC target boards. The OSE BSPs contain all the required board specific code for handling the board initialization and drivers for interrupt controllers, serial communication units, and ethernet devices. SCORE® Support for OSE The SCORE® system has a clean and board-independent interface to OSE which is provided through SCORE’s OSE UCC. This interface is the link between the SCORE® target libraries, primarily the SCORE® Run-Time System, and OSE. The interface has been designed to ensure that hardware and board specific details are entirely within the OSE domain. This means that the SCORE® target code is 100 % board independent and that SCORE® OSE applications can run on any target that has an OSE BSP. The Ada root library has been extended with interface packages containing Ada bindings to the OSE system calls providing a seamless interface from Ada to OSE while maintaining the safety of Ada’s inherent type checking. A special variant of the OSE interface package containing only the IEC 61508 and DO-178B certified subset of the OSE system calls allows the user to check at compile-time whether the application is restricted to use this subset. The complexity of generating an OSE executable based on the numerous configuration settings is harnessed by a few setup files utilizing the dmake tool to automatically generate OSE executables based on the configuration settings. The dmake tool is delivered with OSE and exists in command line versions on both Solaris and Windows NT. The OSE dmake setup performs all stages of the OSE application program build. The SCORE® OSE integration has added support for compiling Ada sources and maintaining Ada libraries within the dmake framework. Based on personal preferences the SCORE® OSE user can choose either to work from the command line using OSE’s dmake setup, or the user can choose to perform the project development entirely from within the SCORE® GUI. The SCORE® GUI support for building OSE applications is twofold:
The SCORE® MLD can be used either from the GUI or from the command line to perform the usual Ada and C source code debugging on OSE applications. The MLD interfaces via ethernet to the OSE debug server on the PowerPC target board to provide Run-Mode debugging. The communication between the MLD and the embedded OSE debug server is completely independent of the host OS and the target board. The only requirement is that there is an ethernet connection between the host computer and the target board. The OSE Illuminator which provides process level debugging of OSE applications can be run concurrently with the MLD. OSE executables can be linked as monoliths or load_modules. A monolith consists of the OSE kernel, the relevant embedded OSE products, and the application code all joined into one single executable which is downloaded to the target and started like any other executable. A load_module has no kernel or other embedded OSE products included. The load_module only contains the application code and it is linked as a relocatable executable which can be placed anywhere in RAM at load time. Running a load_module requires that an OSE monolith has already been downloaded to and started on the target board, and that the monolith has the OSE products included that the load_module requires. The monolith must also contain the OSE Program Handler which assists in the download of the load_module. When a downloaded load_module gets started, it dynamically hooks up with the resources it needs in the OSE monolith that is already running. With the load_module approach, OSE functions like an OS which runs all the time independent of when applications get started and terminated. The SCORE® OSE integration supplements the OSE installation’s application examples with new examples of pure Ada and mixed Ada and C applications which allow the user a quick way to learn how these applications can be configured and how the Ada interface to OSE can be utilized.
On the Front Lines
As Engineering Manager for DDC-I, A/S, Johan O. Nielsen is responsible for all engineering activities in Europe and Asia. Additionally, Johan is the Assistant Product Champion for the SCORE® product line. In his role as Assistant SCORE® Product Champ, Johan works very closely with SCORE® customers as well as the SCORE® development team, deciding the best approach to each customer issue and future releases. During his 16+ year career at DDC-I, Johan has worked at both Europe and U.S. technology centers. His expertise in the Ada programming language, multi-programming language integration and code generation particularly RISC processors, has proven to be a valuable asset. He also serves as an active evaluator and reviewer in the European Union Research Program. Johan lives with his wife Helle and daughter Louise, in Lyngby, a suburb of Copenhagen, Denmark. He enjoys Mediterranean cooking, fine wine, travel, and has a special interest in cars, specifically the large American and fast Italian variety.
3rd Party Update OSE Systems for DDC-I
OSE Systems is the technological provider for real-time operating systems (RTOS) and development tools for distributed and fault-tolerant applications. The OSE™ RTOS was designed from the ground up to satisfy the requirements of today’s complex embedded systems. System designers focusing on reliability, scalability, and simplicity are increasingly making OSE their platform of choice. In addition to OSE’s solutions for communication systems, OSE also offers a safety certified real-time kernel and entire line of safety-critical products, including third party development tools from compilers from DDC-I to modeling tools from Telelogic all optimized for safety critical designs. OSE for Safety Critical Applications Highly Reliable Data Management OSE’s Direct Message-Passing Advantage By incorporating OSE’s highly reliable and highly advanced architecture with state-of-the-art software development tools and modern run-time systems, embedded software designers are truly able to benefit from today's advanced embedded processor technologies. For more information on OSE Systems’ solutions for high reliability and safety critical systems please visit our Web site at http://ose.com/prodserv/safetycrit.
Tech Talk: "Unable to Download to Address" in SCORE® By Karl Rehmer Sometimes when a download for running or debugging fails, you will get a message "Unable to download to address xxxxxxxx”. This means that during the load, an attempt to write code or data to the given address failed. A common cause of this is that the address is not a valid address for the actual target. This is often caused by inadvertently linking in an incorrect version of the “User Configurable Code” (UCC). To check what UCC was linked with the application, you can use the “ucc_id” tool. This tool is invoked from the command line as ucc_id <executable> where <executable> is the name of the program in question. The response will be something like UCC_Variant_PC for an 80x86 bare PC or UCC_Variant_Excimer for a PowerPC Excimer board. From the GUI, open a command window (Tools | Command Window) and then give the above command. The ucc_id tool searches the executable for an identifier that starts with “UCC_Variant” and displays the name. The identifier is defined in the UCC code in the file initialize.c by some code that looks like the following: /* Dummy variable to enable identification of UCC in executable */ char UCC_Variant_Excimer = 0;If you are creating a new UCC for a target board, you should modify the name of the variable to provide an identification for your UCC. If the response from the ucc_id tool is not the UCC for your target, you should relink the application with the correct UCC. The method for specifying the UCC from the GUI is found under Project | Tool Options | C Link | Target Options (if the main program is C) or Project | Tool Options | Ada Link | Target Options (if the main program is Ada). From the command line, the invocation line option depends on the language. For a C main program (the tcc compiler), the option to specify the UCC directory is to specify ‘-Wl:"-U myucc_dir"’ as a target link option or alternatively specify a UCC archive by giving a target link option such as ‘-Wl:"-u myucc.a"’. For an Ada main program, the UCC directory is given to the linker via the option ‘-ucc <directory_name>'. It is also possible to specify the UCC to use by modifying the template file. See the language user guides for details on how to do this.
Patterns in Postmortems By Linda Rising "You must never feel badly about making mistakes," explained Reason, "as long as you take the trouble to learn from them. For you often learn more by being wrong for the right reasons than you do by being right for the wrong reasons." [Juster61] Successful organizations today are learning organizations. We know that knowledge is no longer the business of an elite few, but has become the "business of every business." Today knowledge is power, and organizations are struggling with the best ways to manage knowledge, their most precious resource. We also know that just accumulating knowledge is not enough. The real power resides in sharing knowledge, exchanging knowledge among the members of the workplace. Consider the benefits to the software community if something similar to the following were implemented [Davenport+98].
I take good care of my health. I exercise and eat right. I try to manage stress. I never plan to have coronary bypass surgery. But if I do—I want one of the surgeons in the experiment! Since these surgeons are all in New England and I live in Arizona, I’m left wondering, "Why didn’t these high-powered doctors write down some "lessons learned" and share those techniques, that decreased mortality rate. That way, doctors all over could improve. It’s the same in software development. We see ways of doing things better but many times we don’t talk about it. We certainly don’t do everything we can to avoid making those mistakes in the future. As a result, we keep making the same mistakes over and over. Here’s the way my friend, Norm Kerth sees it in his book on project retrospectives [Milne26 in Kerth01]:
Obviously the importance of knowledgeable people and the sharing of knowledge are not new. Better individual and corporate knowledge has always paid off. What’s new is the focus that is currently being given to this topic. We’re interested in what people know and how to keep them knowledgeable. One way to address this important topic is to look at what the patterns community is doing. They are trying to capture expertise that resides in the heads of experts, document it, and share it. A pattern is simply a way of documenting a solution to a recurring problem. This method of documentation is an effective way to capture what works so it can be shared with everyone. You can read more about patterns in an earlier article. Most designers of object-oriented software are familiar with the Design Patterns text [Gamma+95]. Fewer members of the software community are familiar with patterns that have been written for organization and process [Coplien95] but these may be the most powerful patterns of all. Patterns for organization and process talk about what works at the human level. They describe solutions we can all believe in. It’s just that we never wrote them down! The following appeared in a recent publication [Godfrey99].
Most large organizations have some form of the Santayana review and may call it a retrospective, a postmortem, a postpartum, or project review. The idea is simple—examine what happened on the last project and learn from it. Capture "what worked well" and "what should be done differently." Project reviews provide a wonderful opportunity to capture knowledge as patterns. In a recent article, I described how to conduct a retrospective. In this article, I’ll describe one way of capturing the knowledge from a retrospective as patterns. During a retrospective, comments from team members can be captured and documented. The local process owner or quality assurance person should own these comments. In some organizations, knowledge management is supported across projects. Patterns can be written in any of these settings. It does take time and resources. Nothing worthwhile is free. No silver bullet. The patterns don’t write themselves. Here’s an example of a pattern that was written in one organization. Remember, these are the best practices from other organizations, so pay attention! Pattern Name: No More Than 10 Problem: How many people should be on a team? Context: Product development with limited resources and a tight schedule. Forces
Solution No more than 10 people should be on a team. If the project is large, you may have several teams. Keep the interfaces between the teams as small as possible to minimize communication overhead. [I’ll say more about large teams in a future article.] Resulting Context The small teams can function relatively independently and make the best possible progress toward the delivery date. You’ll always have to fight the urge to add more people. This seems to be the first thing that management wants to do in a crisis. We’re still learning the lesson from Fred Brooks [Brooks95] who observed that adding more women to the job will not produce a baby in less than nine months. Rationale Alistair Cockburn states [Cockburn98]:
Fred Brooks states [Brooks95]:
Brooks [Brooks95] also includes the following explanation of Conway's Law (documented as a pattern by Jim Coplien [Coplien95] ):
Finally, a comment from Donald Norman [Norman99]:
Known Uses The following are from project development postmortems:
Related Patterns This is a rewrite of Jim Coplien's pattern, Size the Organization [Coplien95]. The new name and the postmortem data make the pattern more compelling. Here are some abstracts from other patterns that have been "mined" from postmortems along with some of the comments from postmortems that support the patterns. Some of the patterns have been published.
Get Involved Early [DeLano+98] Establish a good working relationship with designers early in the project. Don't wait until you need to interact with a designer, by that time it is too late. A good relationship must be built over time. This is true for all support organizations, not just system test.
Firewalls [Coplien95] Create a Manager role, who shields other development personnel from interaction with external roles. The responsibility of this role is "to keep the pests away." This pattern fits well with Scrum and other agile processes.
Team per Task [Cockburn98] A big diversion hits your team, so let a subteam handle the diversion, the main team keeps going.
Good Enough Work on the product only until it is good enough. Different products require different levels of perfection, depending on customer expectations. This does not imply producing poor quality products. This means producing products that meet or exceed customer expectations but does not involve effort that is not appreciated by the customer.
A Place of Our Own Locate a convenient space near the team and have it available when they need it. A conference room can be reserved or an empty cubicle can be converted to a meeting space. If a conference room is used, try to book the same room at the same time every day. Free it up if it will not be used. The pattern is closely related to War Room and Team Space [Taylor00].
Lead Architect [Coplien95] Define a lead architect role and staff it with the most knowledgeable engineer, who has the most experience and the best leadership skills.
Co-locate the Team Co-locate team offices. You might be saying that these seem obvious. Of course they are! At the end of every project, when, because you believe in good software practices, you hold a retrospective, what are those lessons learned? Are they startling revelations? Probably not. They’re probably the same startling revelations you had on the last project, and the project before that, and so on. What patterns do is document these lessons and give them a name. Then, in the heat of battle, when we’re pushed to fall back on those tried and not-so-true practices like adding more people, someone can say, "Hey! No More Than 10!" and we can remember stories—ghosts from the past—those stories speak to our hearts and can save us. We can recall all the good things we know and maybe this time, we’ll get it right—or at least a little better! I’m writing two collections of patterns: for conducting retrospectives and for project management (based on experiences with retrospectives). I’d like to hear your stories (everything is confidential, of course). That way, we can all learn. Thanks! When postmortem data from successful teams shows that a team size of no more than 10 is a factor in the success of the project and when those results are backed up by observations by Cockburn, Brooks, Coplien, and Norman, this is an important pattern. Capturing this important information and giving the pattern the name, No More Than 10, is a useful way to ensure that this knowledge is not lost. These patterns can be posted internally and as related patterns are collected and organized, they can be presented to the appropriate audience. In this case, most of the patterns in postmortems are for project management (although some are for developers). Capturing patterns from postmortems is an effective way to ensure that lessons learned about what works and what should be done differently are captured. Since most organizations are concerned about becoming learning organizations, this is a step in that direction. References [Brooks95] Brooks, Fred P., The Mythical Man-Month, Addison-Wesley, 1995. [Cockburn98] Cockburn, Alistair, Surviving Object-Oriented Projects: A Manager's Guide, Addison-Wesley, 1998. [Coplien95] Coplien, J. O., "A Generative Development-Process Pattern Language," Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt, eds., Addison-Wesley, 1995, 183-237. http://i44pc48.info.uni-karlsruhe.de/cgi-bin/OrgPatterns?OrganizationBookPatlets [Davenport+98] Davenport, T.H. and L. Prusak, Working Knowledge: How Organizations Manage What They Know, Harvard Business School Press, 1998. [DeLano+98] DeLano, D. and L. Rising, "Patterns for System Testing," in Martin, R., D. Riehle, and F. Buschmann: Pattern Languages of Program Design 3, Addison-Wesley, 1998. [DeMarco97] DeMarco, T., The Deadline, 1997. [Gamma+95] Gamma, E., R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison-Wesley, 1995. [Godfrey99] Godfrey, A., "The Santayana Review," Quality Digest, Feb. 1999, 20. [Juster61] Juster, N., The Phantom Tollbooth, 1961. [Kerth01] Kerth, N., Project Retrospectives: A Handbook for Team Reviews, Dorset House, 2001. [Milne26] Milne, A.A., Winnie-the-Pooh, Puffin Books, 1926. [Norman99] Norman, D.A., The Invisible Computer, The MIT Press, 1999. [Taylor00] Taylor, P., "Capable, Productive, and Satisfied: Some Organizational Patterns for Protecting Productive People" in Harrison, Foote, Rohnert:, eds., Pattern Languages of Program Design 4, Addison-Wesley, 2000. About the Author 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. |
Introduction to Ada95: --------------- FAA DO-178B Basic Seminar FAA DO-178B Applied Seminar --------------- Seating is Limited!
|
DDC-I Online News is published by DDC-I, 400 N.
5th Street, Phoenix, AZ 85004. Editor Jennifer Sanchez.
Comments and submission of articles are welcome and should be sent to the
editor at the address above or via email at editor@ddci.com.