Rockwell Collins: Ascend
From Devwiki
This is an avionics design and configuration management application. It was originally called ASDD. The goal is create a common design repository for all new aircraft cockpit designs. Rockwell uses it internally and aslo sell it to Boeing and other manufacturers.
Contents[hide] |
[edit] Objectivity Case History
[edit] Important
This information is an archive, so any use of the present sense in the text should be taken in the historical context, generally determinable from the Status section below.
[edit] Customer Information
- Customer: Rockwell Collins Aviation
- Project: Aviation Systems Design Database (ASDD). Now called Ascend
- Location: Cedar Rapids, Iowa
- Territory:
- Industry Verticals: Configuration Management Aviation Controls
- Technologies:
- (look at that page)
- Application Domain:
- Market Characterization: (Remove the irrelevant categories, then remove this clue)
- Number of developer licenses:
- Runtime license volume and type:
[edit] Status
- First Contact: 1997?
- Lead came from:
- Evaluation Start Date:
- Evaluation Finish Date:
- First Purchase Date: 1997?
- Deployment Date: ASDD was deployed to the preliminary design review developers. To the Boeing Cockpit project. Deploy to the Critical Design Review Developers – October, 1998. Internal deployment of ASDD – Oct’98
- Current Status: Deployed.
- Can we talk about this customer and the product/project? Yes
- Referenceable?: Yes
[edit] Environment
- Hardware: VAX, then Intel.
- Operating System: Originally a big part of the Objectivity decision was the fact that it was the only ODBMS to support VAX/VMS. Luckily they gradually moved to first Windows 95 and then Windows NT as we dropped VMS.
- Precision: 32-bit
- Development language: Microsoft Visual C++
- Compiler: OS standard.
- Third Party vendor tools: Rational Rose
- Open Source tools: Python
[edit] The Project/Product
[edit] Project Background
Our direct customer is the ASDD development group headed (at that time) by Lenny Hoffman. In turn his customers are other project teams which will use the infrastructure and end users (engineers) who are using the first implementation, SAGE.
The ASDD application is now going to also be used in the new Advanced Technology Groups core software infrastructure suite. This called the Pro-Line 21 architecture. This internal, company-wide initiative is funded by Rockwell. It becomes part of a Cost Center to the Advanced Technology group at Collins. They are enchancing the initial ASDD application to include configuration management tools, change management processes, and audit processes. In Rockwell’s ASDD application product, Objectivity/DB is the embedded solution, which manages, and stores all objects and relationships with respect to the design of large aircraft cockpits. This end-user product stores relationships and objects like electronic flight instruments, displays, autopilot/flight directors, weather radar intelligence, and com/nav/surveillance sensors. This new application will allow the design developers to re-use previous design information from old cockpits and airplanes. They will not have to start over from scratch like they do today. This ASDD application shall significantly reduce the cycle time for developers designing new aircraft cockpits, and eventually other areas of the aircraft. Subsequently, this shall save Rockwell and Boeing (Rockwell Collins’ largest customer) development money and time with respect to introducing new commercial and defense avionics solutions.
[edit] Project/Product Description
The goal of the project is to create a common design repository for all new aircraft cockpit designs. The repository promotes reuse of design specifications and has the intelligence to verify compatibility of components in new designs. The repository is an infrastructure component set up to be useable by several engineering applications (many as yet undefined). The same group is also doing the first implementation called SAGE (no particular meaning) it has a slick Web Browser-like interface to enter components, connect them for a complete cockpit design and make changes.
It is being used to store component definitions, their properties and rules for connections among them. Objects represent boxes, wires, data transferred over the wires, the format, frequency and quality of the data transferred. They also store a complete Meta-Data model and all the information needed for “Intraspection” (total knowledge of what all the pieces of the model mean and rules for relationships). Other objects are stored for their own Event Notification.
ASDD is primarily C++ but they are also using Python which is used to indirectly manipulate Objectivity via the ASDD layer and its metamodel and intraspection rules. One of the other groups within Rockwell is planning to use ASDD in its application, which will be written in JAVA.
Rational Rose is used to document their model, not for code generation. They are moving toward UML.
MFC is used for part of the GUI implementation of SAGE. They have invented their own WYSWYG HTML interface, which can not yet be done with MFC. STL has been used (without the Objectivity support) for (among other things) maps and Indexes.
They can generate HTML for web access that looks identical to the native interface (read only).
Event Notification: Again, they have built their own. It uses “simplified polling” at a less granular (container) level where a transaction can register an interest in a container (not an object). If that container changes, the transaction receives an event log that the transaction analyses to determine the impact. Because there is no central registration point there is no bottleneck and this becomes highly scalable. Lenny compares it to the Objectivity distributed architecture where each computer shares the load avoiding a central bottleneck.
Configuration Management: They have built in the ability to have multiple concurrent changes (versions) to the same design. This is true configuration management, several levels deep using polices which go beyond referential integrity (this is total data integrity) or simple version control.
[edit] Buying Criteria
[edit] Business Priorities
Q. What does the customer consider value?
A. Lenny has always considered the value in Objectivity to be in its distribution, scalability, performance and ease of use. Ease of use includes not needing to write mapping code and Objectivity’s automatic associations and related methods and enforcement of referential integrity. Lenny has always been a big fan of STL. He used it in the ASDD application before it was supported by Objectivity. He is now using our STL support and considers that to be valuable. Finally, he sees schema evolution to be a very valuable feature in this dynamic development environment.
Q. Are we delivering value?
A. In some of the above we have not met expectations. He has implemented his own associations to avoid the time-consuming complexity it adds to DDL. He has also run into some quirkiness in our initial implementation of STL and Schema Evolution but feels we will work this out over time.
They now feel the real value we provide is a “Basic Engine” to hide the complexities of persistence, network (IP) handling, basic data integrity and transaction handling. Scalability because of the distributed client, distributed server nature of Objectivity is also of great value to them.
Q. How has Objectivity helped differentiate their product in the marketplace.
A. Even though their customers are internal, they do have other choices. The biggest differentiation is the ability to do true configuration management (several levels deep). Other initiatives within Rockwell have been unable to do this due to the limitations of relational databases. With ASDD, if something changes only that object needs to be changed. With relational, all related rows must be changed and code complexity increases while performance drop. As Lenny says if you try to do with relational what we are doing in the area of Configuration Management “You might as well just shoot yourself”.
[edit] Technical Priorities
They began their selection process in the summer of 1995. They looked at only object databases because the felt relational would be too slow and require writing too much code. After presentations from Objectivity, ODI and Versant, they chose Objectivity for further prototyping and benchmarking. After about a year of testing they made their first purchase and began developing ASDD.
Features used:
- Indexes: No, they use STL.
- Maps: No, they use STL.
- Named Objects: They use one as an entry point. Most of the rest of the lookups are navigational.
- Associations: They have implemented their own bi-directional associations with policies defined in the metadata model, which trigger creation of the proper relationships.
- Versioning: No, they do their own Configuration Management.
- Predicate Query: No, they use their own “Intraspection” for navigational based, intelligent searching.
- SQL: Considered this but decided to do reporting with Python.
- ODBC: Considered this but decided to do reporting with Python.
- FTO & DRO: Possibly in the future.
- Schema Evolution: They are creating their own dynamic schema using the metaschema built into ASDD.
- Heterogeneity of O/S: Planned initially but now all Windows XX.
- Heterogeneity of Language: Yes, initially C++ but JAVA will be used in the future.
- Multithreading: Not needed in their design.
- ODMG interface: Not believers.
- STL: Yes, although mostly their own.
- Containers? Since their configuration management uses change packages where everything under change is put in its own temporary container, everything else is basically read-only. Since there are no concurrency issues, they put everything in one container until they have a need to break it out. This is done administratively. Thy can recontainerize anything, anyway they want at any time for future flexibility.
- Transactions: They use short transactions under their GUI. All read transactions are MROW. Every user action creates a transaction that accomplishes everything the metamodel’s rules require. No transaction is left open while a user looks at the screen. They may need to add checking for changes since the data was displayed to avoid walking on updates since the display. This is a slight exposure because of the way their Configuration Management does changes in a separate container via a “Change Package”. The exposure here is only when more than one engineer is working on the same change package at the same time. They believe this can be done with a compare to the screen data before updating.
[edit] Competitors/Alternatives
[edit] Why They Chose Objectivity
- Support for VAX/VMS was important.
- SCALE WITH MANY USERS CONCURRENTLY. GOOD REFERENCE POINT FOR THIS FEATURE WITHIN OBJY/DB FROM A DEPLOYMENT PERSPECTIVE. GOOD PERFORMANCE AS THE NUMBER OF USERS HITTING THE APPLICATION GROWS.
- Objectivity has been instrumental in keeping track of all Rockwell’s complex objects, which also have complex relationships within the ASDD system.
- In addition, Rockwell would not be able to scale to the number of planned designers/users unless they used our distributed object engine.
- Furthermore, they want to be able to increase the functionality and features of this system seamlessly overtime. They are impressed and confident that our schema evolution and versioning features will give them the ability to introduce new functionality to the ASDD without hampering the designer’s productivity.
- Finally, this application needs to provide 24X7 service to a large number of concurrent users who are distributed all over North America. Hence, another reason why Rockwell chose Objectivity/DB is due to our “Hot Fail Over” capabilities; better known as our Fault Tolerance and Data Replication features.
[edit] Partners
- DEC
[edit] Collateral
- Press Releases:
- Fliers:
- White Papers:
- Case Study:
- Other:
[edit] Contact Information
- Objectivity Rep:
- Customer Contact:
- Customer Phone:
- Customer Email:
- URL:
