| From Mainframe to Intranet | Table of contents | Indexes | Digital documentation trends for aircraft maintenance | |||
| Schiller Jörg |
SGML and development documentation |
Abstract: |
| The development ofECU (electronic control unit) for cars is a highly parallel and complex job. Requirements from different parts of an automotive manufacturer have to be fulfilled. The interfaces between correlated persons are not defined in a way, that an exchange of information is done easily. Business process reengineering activities discovered a big potential for enhancements by using SGML technology as an overall exchange format in these areas. |
| Several projects were started, to implement a new process model. This article describes our experiences in projects we realized since the beginning of 1995. |
| The biggest project deals with diagnosis data that is needed to describe parameters to communicate withECUs . Today you can get many informations about the actual state of internal and external variables ofECUs (for example a coolant temperature). These informations are used to guide a diagnosis process to determine erroneous behaviour of components of a car. The diagnosis data is used in different parts of the company (development, production, service). Even companies that deliverECUs can be involved in this process. We started a case study to determine the best format for the description of structures. As a result we decided to take SGML. The Document Type Structure (DTD) is presented to the ASAM/ASAP consortium for standardization. This consortium represents the German automotive industry, suppliers and tool companies. |
| A second project defines a structure for the exchange of requirement specifications between suppliers and automotive manufacturer. The goal is to combine the developing processes and to realise a small reaction time on fast changing requirements. |
| The project is based on a DTD that is defined in the MSR consortium which consists of European automotive manufacturers and supporting companies. The tools for the authoring environment, data management and conversion of these informations are completely based on SGML and HyTime. Companies today reside in different countries world-wide so that a multi-language processing is needed for the documentation. We had a three phase development process in nearly every project. First of all we started with the definition of the DTD in a very thorough process. The second phase was the implementation of the authoring environment. We finished with the development of the connection between the authoring environment and the database management system. This step included the implementation of workflow concepts for the distribution of the information. |
| The world of cars and trucks is met by a huge list of requirements from the customers and from the legislature. On the one hand there is the demand for highly comfortable cars with all the features for business aspects and leisure pursuits. On the other hand there are strong security and environmental restrictions for such vehicles. These requirements can only be solved by complexECUs (electronic control units) . The firstECUs were implemented for exactly one problem and could be seen as a standalone solution (motor management, air-conditioning system, airbag). NowadaysECUs have to be connected to each other over networks to spread the information they collect from their sensors (motor management and gearing system). Confronted with this complexity it is clear, that the development and the testing of such an integrated system costs a enormous amount of time. |
| The developer of anECU has to get a lot of information from the system about the status of hisECU (for example the coolant temperature), to guarantee the correct functionality he designed. For this purpose protocols over serial connection lines and diagnosis test tools were implemented to solve the problem. We collected a lot of experiences that are correlated to these problems and implementations. |
| A few years ago we were confronted by a situation, where different diagnosis applications (supplier ofECU , automotive manufacturer, even inside the same company) were using different data structures to define their informations that are needed to keep the systems running. It took a big effort to describe in multiple formats the way anECU delivers his informations. So we were asked to define a format that is common for all these applications to reduce the cost for editing and testing the data. |
| The first idea was to define a new format based on a data base to solve the problem of data management and distribution. When we started to talk to the users of that data in the different companies and departments we saw a lot of undocumented and undefined processes for the authoring, conversion, delivery and the storage of diagnosis data. In that phase we recommended our customer to start a business process reengineering project for this diagnosis area. The first results of that still working project showed, that there are a lot of concerned instances and that a few of them took SGML (J2008) to describe information, that they interchange. We saw the advantages of SGML very rapidly and decided to take a closer look to the standard and the availability of tools. As we started the project for the description of diagnosis data our decision was clearly saying SGML. The project was divided into three phases: |
|
| The development of the DTD was not that hard to do. Our first prototype showed up very early and is not that far away from the actual version, that we use in the moment. The most costly part was the collection of the information from the users and the acceptance of the suggested solution. We designed a content oriented approach because we wanted to connect the working processes as close as possible. TheECU address for example can be taken directly to stimulate the communication to anECU . The type model in SGML is not that extensive to describe ourECU address as a hexbyte. We needed this type information to avoid erroneous entries in the data. To solve this problem we described our own type model with regular expressions in SGML attributes. |
| The editor was developed to a syntax oriented editor with as much of assistance in the user interface as possible. We also developed a context sensitive online-help that gives help on every element of the DTD. As we know there is by now no comfortable DTD to helpfile converter that we could work with. So it was a lot of work to do to keep the online help actual with the changes of the DTD over time. We made one big change to the DTD as we implemented HyTime features to describe links between documents. The editor can handle those links. |
| The data management of the SGML files was the starting point of the development of a connection between the editor and the SGML database. As a first approach we implemented a cold integration (loose coupling) to open and save on document level. For the diagnosis data project it was a good and fast enough solution, because we are working with quite small documents. For another project that describes requirements specifications the document size is that big, that a cold integration is to slowly. In the moment we are specifying a warm integration (tight coupling) and hope to implement it in one of our new versions of the system. To support parts of the new process model we had to define and implement a status model for documents. In the moment the status is a part of the diagnosis DTD. With better support of the tools we hope to split of these information with the help of the database. The model describes different user roles with different rights to read or change documents. The authoring environment allows the user to change the status interactively. The system will change all the appropriated elements and attributes of the SGML instance. |
| The system is now in use by 10 to 15 users and will grow in 1997 to 30 to 50 users. There is a process of standardization of diagnosis data in the moment in a consortium called ASAM / ASAP. Our DTD is a proposal to that committee and we think it will be fixed till the end of 1997. Our experience with the technologie SGML are quite good. We can transport the concept very easily to the users. There are only two points where SGML is quite weak. The one is the poor type concept and the other is the definition of security and workflow mechanisms in SGML. |
ACKNOWLEDGEMENTS |
| I would like to thank Mr.Bodensteiner from Mercedes Benz AG for his help and assistance. |
| From Mainframe to Intranet | Table of contents | Indexes | Digital documentation trends for aircraft maintenance | |||