|
|
|
|
||||
| August 2002 | Vol. 3 Issue 7 | |||||
|
|
Inside This Issue
|
|||||
|
****** NEW! ****** |
TADS-1750A Launches the
Incorporating numerous systems developed for the flight-proven Atlas III, development of the Atlas V — the most powerful Atlas launch vehicle ever built — began in 1998, to meet the growing needs of the U.S. Air Force Evolved Expendable Launch Vehicle (EELV) program and International Launch Services (ILS) commercial and government satellite customers worldwide. "Every Atlas variant during the past ten years has had a flawless first flight," says ILS President Mark Albrecht. "With a modular design and increased capability, the Atlas team provides a vehicle that meets a wide range of customer needs. To the development team, I say thank you." According to Michael Bethancourt, Flight Software Development Lab Manager and Team Leader for the Atlas Flight Software Operating System (OS) group, the flight software package begins with the preflight checkout before performing guidance, navigation, steering, flight sequencing, autopilot, engine control and fluid & pressure management operations during actual flight. The Atlas V also features unique, in-house developed ROM, BIT and Operating System software. "We have a highly experienced team, and what we did, moving from Atlas II to Atlas III, was to restructure and layer the OS in a more object-oriented fashion. This affected much of the Atlas III software" he explains. "When we started on Atlas V, what we did was bring forward our sophisticated and proven control algorithms and implement them into a software structure that was fully object-oriented. We employ a number of powerful Ada95 features, not all of them, but we essentially have Ada95 here." He adds that Ada is the appropriate language for much of what they do. The modern features that are critical to building reliable and robust flight software, including strong typing, dynamic binding, polymorphism, and a secure environment merge to produce far fewer interface errors, and an effortless enforcement of proven development standards. "Ada is definitely the right language for mission critical, safety critical, real-time embedded systems" he adds. Describing the stability and performance of the AdaTest95 processor and the file-coupled TADS system as "turnkey," he adds that the multi-window interactive symbolic debugger within the 1750A simulator and target chipset is a major advance over previous development subsuites. "We have a homegrown debugger built into our flight box downstairs for Atlas II & III. We did full module testing on our test set downstairs, using capabilities written years ago on a DEC VAX. We still do full module testing for II & III on the VAX and we go down and do our branch testing on that flight-equivalent test set." The branch testing combined with the Computer Software Component and system testing — where the software is "flown" against a simulation of the vehicle — provides the team with solid confidence in the reliability and robustness of their software. "With the Atlas V, instead of having to do all of our branch testing on the single test set, now we can run against any one of a number of single-board computers with the debugger in place. We can sit up here at our desks and test on computers that are actually located in our Software Integration Laboratory that is nearly one mile away. We get much more accomplished, and the whole process is just more productive." With 34 years in software, including a stint teaching OS internals, and 26 years of hands-on experience in the real-time embedded systems world, Bethancourt is well-equipped to comment on the state of programming tools and the value of solid support from the vendors. Though as a Lockheed Martin employee he can not endorse products or vendors, Bethancourt’s feelings about DDC-I and the TADS programming tools are crystal clear: "DDC-I has demonstrated that they understand the importance of responsiveness. During the Atlas V development phase, the representatives visited often and quickly deduced the critical nature of the software we’re building and flying. As a result of their early interest and continuing concern, we don’t have to worry about the development suite, and are able to direct our full attention to achieving 100% Mission Success" he says.
DACS
Multi-Application By Thørkil B. Rassmussen DACS Multi-Application Programming with Paging
The traditional cross environment consists of a single, monolithic application (program), linked with the proper Run-Time System (RTS) and User Configurable Code (UCC), loaded onto the target in one of several ways, and then executed, possibly indefinitely. Such an application can be debugged, when it is loaded by the debugger. It is desirable to split this one application into several smaller, simpler applications, perhaps with different priorities, capabilities or rights. This can be modelled to some extent assuming a set of tasks for each application, and providing each with proper attributes. Often, however the smaller applications have some parts in common with each other. This led to the idea of allowing the common parts to be shared by more than one application. First it should be noted that an application fundamentally is a set of tasks; one of these is the main (anonymous) task, another the null task, and the rest the proper tasks. Running an application consists of starting its tasks. The tasking kernel (included in the RTS) could already switch between tasks according to the rules of Ada, so fundamentally there is nothing to prevent a switch from a task in one application to a task in another. Second, the tasking kernel should be separated away from each application and be common for all. This requires a full, common RTS with a tasking kernel that is resident all the time (the System RTS), as well as a minimal RTS (the UOP RTS) which relies on the System RTS and is linked with each application. Access to the System RTS from the minimal RTS uses the 80x86 call gate mechanism, which allows each application to be linked separately. The tasking kernel is primarily configured with all the task control blocks (TCBs) and with all the application control blocks (ACBs). Each task belongs to one and only one application. The System RTS with the tasking kernel is placed in the first application, which can be a debug monitor or another special application. Third, all code and data other than the control blocks are provided by the applications themselves. For example, the information that allows a heap allocation to take place on behalf of an application is recorded in the ACB, when the application initially signs in. Fourth, to make optimal use of memory, paging and virtual memory are used. The first application initially owns all of the memory, and what it does not use itself is recorded in free-page lists. Applications signing in ask for pages for all the data and code they require, and only if this is available are they allowed to start. Certain pages can be mapped to certain physical memory (e.g., video memory or DMA areas). Fifth, applications are divided into two groups: system and user applications. System applications will be in the system virtual address space all the time, requiring them to be linked so as to not overlap each other. These applications are trusted, and they can handle interrupts, provide call gates, and allow other applications to call them. User applications are restricted in the instructions they may execute (via hardware level 3 privilege mode), and may share virtual address space with other user applications, but not with any of the system applications. User applications cannot see each other, and they cannot see the system application information, but they may enter a system application via the call gates. With the introduction of user applications, the tasking kernel would have to take into account that a page table (visibility) switch would be required when switching between two user applications. Sixth, the debugger should be able to 'break in' to a running system and determine which applications are executing. This is achieved by interrogating the list of ACBs currently active. Commands to unload running applications, to load new ones, or simply to connect to one of the running applications are provided. Similarly, the debugger can withdraw from the system and let it run on its own again. Seventh, if an application is executing in its own code, debugging should take place just like in the traditional one-application case. However such an application may be executing in another (system) applications's code which it called through a gate. In this case, the debugger can connect to this other application and debug symbolically there. Call chains may therefore contain elements from more than one application. Eighth, the debugger has been extended with a target-attach concept that allows the same debugger session to be attached to more than one target board at a time. If target boards are communicating, a transmission from one board to the next may be caught if a breakpoint was present at the right place when the transmission commenced. Commands to switch between targets and to attach or detach are provided. Conclusion: The multi-application system allows for a late configuration of the set of applications for a target board for a given task or mission, and it may even be decided to leave out some less used applications initially. The user may decide to load inspection applications later that can check proper system function, or may break into the target to look at it, with a later withdrawal. This gives a great deal of versatility, as trusted applications can remain as they are in many configurations and need not be linked again and again as part of other applications. The multi-target capability also makes debugging of complex target board setups possible. DDC-I's multi-application programming with paging (MAPP) extension can be of great advantage to customers with complex needs, involving several target configurations and/or several boards, and requiring full symbolic debugger support all the way.
On the Front Lines
As a Regional Sales Representative, Carolyn Bisby is responsible for sales related activities for northeastern U.S and eastern Canada. In her role as Sales Rep, Carolyn is authorized to represent DDC-I for existing customer relationships as well as new sales in her territory. Carolyn began her career at DDC-I in February 1998, handling sales of technical support packages and product shipment logistics. This experience is helpful for existing customer care activities, as DDC-I sales reps are actively involved with the customer for the life of their program. An active member in her community, Carolyn participates in judging for Future Business Leaders of America competitions. She worked for numerous years as a High School Career Counselor, earning numerous awards including "Who’s Who Among American Teachers" and "Outcome Assessment Steering Committee for North Central Accreditation". Carolyn lives in Chandler, Arizona with her husband Jim. She has three grown children, Dirk, Toni, and Tyson. She enjoys traveling with her photographer husband searching for landscape photo opportunities. For more information on Front Liners and DDC-I's organizational structure click here.
3rd Party Update
Vector Software, Inc. is a leading independent provider of automated test tools for software developers. Established in 1989 as a consulting and service organization, Vector's product focus is to empower software professionals to deliver the highest quality software in the least amount of time. Vector's "VectorCAST" line of products reduce the burden placed on individual developers by automating and standardizing application component level testing. This innovative technology developed by Vector represents the "next generation" of intelligent test tools. The tools support Ada, C/ C++ and Embedded C++ (EC++). VectorCast has been integrated with DDC-I's SCORE (Safety Critical Object-oriented Real time Embedded) and DACS (DDC-I Ada Compiler System) toolsets.
Tech Talk: Multiple Users Can Easily Share a SCORE Project By Lisa Jett Using SCORE, many members of a project team can easily share a project and maintain their own repository (or work area) for source code files. The SCORE GUI supports a built-in macro called USER_SRC_DIR that can be defined at both the "project level" and at the "user level". This means there can be a default project-wide setting for where the source code files reside and that each user can also define their own location for their version of the project files where they can make changes to the code without affecting other users. Defining the location of source files for a project at the project level When a project is created (in project mode), the project can be defined to have a location for the source code files. Follow the following steps to create a project to be shared by many users and define the common directory for source code files.
Defining the location of source files for a project at the user level Now that the project has been created, each user can define their own private location for the source code files. Follow the following steps to define a users private work-area directory for source code files.
The files are still stored in the program with the USER_SRC_DIR macro for the location of the files, but for the current user the user-level defined directory will be first used when the GUI tries to open a file, etc. In this way, each user can keep and use their own copies of the files in a program to test changes, etc. without affectiing other users.
|
Introduction to Ada95: --------------- FAA DO-178B Basic Seminar FAA DO-178B Applied Seminar --------------- Seating is Limited!
|
The
maiden voyage of Lockheed Martin’s first Atlas V rocket is scheduled
to liftoff from Space Launch Complex 41 at Cape Canaveral on August
12, 2002, freed from its earthly bonds by flight control software
created with DDC-I’s Tartan Ada Development System (TADS).
DDC-I,
in cooperation with a large U.S. customer, has created an extension to
the traditional DACS-80x86 cross compiler environment for 32-bit, flat
mode Pentium targets that introduces the ability to have more than one
application executing on the bare target at any time.
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.