Barco Graphics
advertisement
[hier komt het titelblad van Stefan] SEESCOA PROJECT BARCO VISIT REPORT Contents VISIT DETAILS 2 SUMMARY OF PRESENTATIONS 3 Barco Graphics (BG) presentation 3 Barco Communication Systems (BCS) presentation 6 Barco Display Systems (BDS) presentation 8 EVALUATIONS AND SUGGESTIONS 10 Barco Graphics 10 Barco Communication Systems 11 Barco Display Systems 11 APPENDIX A: SW ENGINEERING METHODOLOGIES AND TOOLS APPENDIX B: DEBUGGING METHODOLOGIES AND TOOLS APPENDIX C: REAL-TIME OPERATING SYSTEMS APPENDIX D: GUI METHODOLOGIES AND TOOLS 1 SEESCOA PROJECT BARCO VISIT REPORT Visit details Location: Barco Graphics Tramstraat 69 9000 Gent Date: Thursday 10 February 2000, 14.00 - 18.00 h Agenda: 1. Introduction of Barco Group - Kurt Michels (?) 2. Barco Graphics - Ronny De Loor 3. Embedded Software Development in BCS - Steven Soenens 4. Software Engineering for Embedded Systems in Avionics Luc Vandormael 5. Conclusions - Kurt Michels (?) List of participants (Partners): RUG: Mark Christiaens Koen De Bosschere Michiel Ronsse [email protected] [email protected] [email protected] LUC: Karin Coninx Jan Van Den Bergh Stefan Verkoyen [email protected] [email protected] [email protected] VUB: Theo D’Hondt Viviane Jonckers Tom Toutenel Werner Van Belle [email protected] [email protected] [email protected] [email protected] KULeuven: Yvan Barbaix Yolande Berbers Kris Hermans David Urting Stefan Van Baelen [email protected] [email protected] [email protected] [email protected] [email protected] 2 SEESCOA PROJECT BARCO VISIT REPORT Summary of presentations The Barco group consists of six divisions: Barco Automation (BA) Barco Machine Vision (BMV) Barco Projection Systems (BPS) Barco Communication Systems (BCS) Barco Display Systems (BDS) Barco Graphics (BG) Three divisions (BG, BCS and BDS) had a representative who gave a presentation about software development in their division. This chapter highlights these presentations and reflects the insight the consortium gained in their development process. Barco Graphics (BG) presentation Application domain BG produces all kinds of printing and packaging systems. One application in particular is presented: the PlateSetter product. It can be compared with a “huge” network laser printer for printing with high resolution (2400 and 3600 dpi) on large aluminium sheets. The total product consists of a Windows NT machine and the printer machine that hosts several customtailored hardware boards. The NT machine: processes the images hosts a soft PLC for controlling the robotics The hardware boards: control laser heads and other optic equipment using PID controllers are connected with the NT machine by means of a direct TCP/IP connection between the devices. Typical software characteristics are: 3 SEESCOA PROJECT BARCO VISIT REPORT hard real time: interrupt rate of 2500 Hz and a latency of maximum 30 sec soft real time: PLC events at a rate of 20 - 50 Hz with an average of 10 msec There are no real memory constraints (32 - 64 MB available) The team consists for 20-30% of software people. The development took about 10 man years: 4 man years was spent on base level software, 6 man years was spent on application level software. These 4 man years were due to several integration problems with 3rd party components (RT kernel, TCP/IP, …). Software development process As a preparation for this presentation, the development team of BG had a meeting for identifying their development process. This was necessary since BG never explicitly identified their process, so this was an illuminating experience. Requirements should come from customer interviews, but since the customer has no clear picture of what he wants, most of the specifications are gathered via internal brainstorm sessions. Requirements are described in use cases that are written down using Word and Excel. Non standard block diagrams (in pen and paper style) and additional brainstorm sessions are used for analysis and detailed design. During this phase an API is defined. In parallel the user interface is created using Visual Basic. The customer then evaluates this GUI. His feedback provides extra information concerning the correct functionality and presentation of the application on screen. Coding is done mostly in C/C++. A little amount of Assembler is used for porting the RTOS to the custom hardware. Visual Basic is used for the GUI and a software package (InControl) is used to program the softPLC. Testing and debugging is a straightforward process, which reminds of the “Extreme Programming” technique1. The person who writes a piece of code also writes dedicated test shells. He thus tests his own code when he writes it. The prototype evolves towards the finished product by adding and debugging little pieces and testing them during long day runs. Integration of code from different authors is done on an ad hoc basis. The different persons involved, gather around the table and solve the problems as they arise. 1 “Software Engineering in the small”, IEEE Computer, Vol. 32, No. 10, October 1999 4 SEESCOA PROJECT BARCO VISIT REPORT Deployment and version control is done using standard software packages (InstallShield & ClearCase). The general conclusion at BG was that they use a sort of spiral model. Repeatedly and alternating coding and testing until the final product is ready. There is also no believe that existing CASE tools will increase productivity. However, an ideal tool description is given. This ideal tool should allow for: An integrated development processors and architectures environment for different Code generation from state machines Documentation generation Memory leak finding Interrupt service debugging Variable tracing Development tools Coding is done using the following tools: Microsoft DevStudio Nucleus EDE InControl IEC 1131 Visual Basic ATL (Active Template Library) Debugging is done with the aid of: Visual Studio debugger “print” commands Reuse and components There is a basic form of re-use: standard C and C++ libraries and API’s are used and when during application development pieces of code seem more general, an ad hoc application driven library is developed. Experiences with third party libraries are negative: one has to fix problems at the source code level for a clean integration. 5 SEESCOA PROJECT BARCO VISIT REPORT A standard software package (ClearCase) is used for versioning. In the presentation, BG gives also some definitions for what they see as components. A component is a collection of routines and classes. It has a clear interface and is self-supporting, meaning that a component is an independent unit. Some examples of useful components are mentioned: board support packages, communication and GUI components. Barco Communication Systems (BCS) presentation Application domain BCS is active in domains of: Analog CATV equipment Digital service distribution MPEG2 encoders/decoders Fiber optic supertrunc systems Broadcast equipment Network monitoring Management solutions This domain is characterised by small, networked devices intended for a mass market and it has as a consequence a stringent price competition. These systems need an integrated management system for remote diagnostics, performance monitoring, fault detection and security policies. Some of the most challenging evolutions in this domain are: Growing bandwidth Open interfaces (Rosa, SNMP, …) More processing power Short time-to-market Bigger development teams with faster development More complex software designs Low power consumption and hot insertion 6 SEESCOA PROJECT BARCO VISIT REPORT Software development process The speaker expressed his doubts about a unified software development process. According to him, every project has a different process, but one can recognise common phases and activities. At the early design stage, a small team creates the top-level block diagrams, which represent the main packages. Per block there exist several use cases and message sequence charts (MSC’s). This top-level design is then extensively reviewed and discussed with other persons, who are sometimes not involved in the project. When every one feels happy with the design, an incremental and parallel refinement is carried out. How soon the actual code is written depends from person to person. Some developers want to dive into code as soon as possible, others feel more comfortable with additional higher level refinements. The overall goal is to have some “visible” results within a predetermined period of time (e.g. within three months). Several ad hoc design notations are used, but there is a shift towards a subset of UML (class diagrams, collaboration diagrams and state charts). In the future a gradual extension towards use cases and code generation is planned. Development tools Because of the variety of architectures and the lack of good (easy-to-use) existing tools, only very elementary programming tools are used: compilers, debuggers, makefiles and custom scripts. Also importance is attached to programmers guidelines and use of mailing lists for exchange of information. Reuse and components There are cases where code re-use (and even design re-use) can be applied, but this is not an enforced process and is rather based on the experience of the project leader and participants. The importance of reuse is recognised though, but it is not applied in general. The speaker expressed several needs, which can all be tracked down to a need for re-use and components. So for example they use a RTOS because of the real-time requirements, but also because of the re-use of the system code and the ability to plug in third party protocol stacks. A big problem however with this approach is the difficult integration of several components and the lack of tools to do this properly. 7 SEESCOA PROJECT BARCO VISIT REPORT Barco Display Systems (BDS) presentation Application domain Barco Display Systems provides high performance display products for critical defence and aerospace applications. The Barco Avionics Family concept focuses on three major parts of the cockpit man-machine interfacing: the Control Display and Management System (CDMS), the intelligent Multi-Function Display (MFD) and the dumb Cockpit Head Down Display (CHDD). The architecture is built around an open and modular architecture integrated into the general purpose Avionics Processing Unit, which allows BARCO to adapt the different products to individual customer requirements. The Avionics Processing Unit houses all the option boards such as high-end graphics generators, ARINC 429, ARINC 629, MIL-Std-1553, Synchro/Discrete/Analogue interfacing, Video RS-170 and PCM-CIA Dataloader. All the option boards are identical for use in both the CDMS and MFD. The software must manage various tasks, such as: Initialisation of the hardware Communication interaction between the units Guaranteeing timing requirements of communication protocols Generation of symbols and pages Execution of self-tests Execution of tests on redundant units The delivered software has to meet several “safety-criticality” standards and has to be completely predictable (for timing and memory consumption). Software development process BDS uses the V-model development process. This process consists of a number of phases: System Requirement, Software Requirement, Architectural Requirement, Low Level Requirement, Coding, Unit Testing, Module Testing, Integration Testing and System Integration Testing. These phases are traversed sequentially and validated at the end. The results of a phase comprise a number of standardised documents. Each phase has to conform to certain standardised rules and has to be carried out independently. A lot of interaction with the customer guarantees that the product will meet its specifications. In addition, the specifications have to be traceable throughout the whole design and into the code. 8 SEESCOA PROJECT BARCO VISIT REPORT As a consequence, this process model needs a lot of automatisation tools: code generation, document generation, consistency checking, etc. Typically, 20% to 40% of the total development time is spent on testing, about 30% on documentation and only 30% to 50% is spent on coding. Development tools This is a list of the used tools at BDS: CASE Tool (Rose) Development tool (Apex) Cross Compiler (Apex or ARTK) Minimal Ada Runtime Kernel (MARK or C-SMART) Configuration management (Apex/Summit) Static analysis (AdaAnalyser/AdaRepair) Dynamic analysis tool (TestMate/-Cross) Logic Analyser as Measurement tool Automated Documentation Generation (SoDa) Display prototyping / code generation (VAPS) Reuse and components There exist many opportunities for re-use: Re-use of hardware modules gives the opportunity to re-use control software. These unmodified software modules have to be integrated Re-use of a hardware module for a different application makes it possible to partly re-use low-level software A similar application can use existing software as a template (re-use of design) In a component oriented approach, re-use of the model and code and documentation is intended. In that case, if one can prove that a component remains unchanged, it doesn’t has to be individually tested and documentation can be copied. 9 SEESCOA PROJECT BARCO VISIT REPORT Evaluations and suggestions [inleiding] Barco Graphics Strong points Good balance between PLC software, dedicated RT processor boards and standard software for coordination. GUI architecture for remote monitoring and diagnostics is maintained. Possible tracks for improvement Introduce a good Software Development Process. This will become essential at the moment the software gets a higher impact on the total product. Investigate software development and design techniques, such as architectures, frameworks and design patterns to improve the overall design. Test more rigorously. Integration testing goes further than applying it only on the prototype product under development. Use of design tools helps to improve the Software Development Process and provides a support towards document generation. Improvement of API documentation, including UML models and precise description of avoids a large number of integration problems. Do not neglect security of remote access and diagnostics. Improve the re-use of development effort and code by means of component development and a re-use plan supported by a component library that contains components having their own requirements, design, documentation, test plan and version. A relaxation of the component definition to allow components to use other components opens possibilities of developing and reusing higher-level architecture components 10 SEESCOA PROJECT BARCO VISIT REPORT Barco Communication Systems Strong points The speaker’s responsibility is to follow up several projects concerning embedded system development. This has the advantage that knowledge gained from one project can influence other projects. Good architecture of management interfaces: remote configuration, monitoring and diagnostics integrate easily with system core Possible tracks for improvement Introduce a structured re-use model. This increases the probability of re-using a component, for instance by implementing a (company wide) global database with descriptions of developed components and libraries Use a standard Software Development Process to enforce more component-based development, rigid component documentation and a systematic attentiveness for re-use Adopt design tools to improve the Software Development Process and to provide a support towards document generation The Ace Orb (http://www.cs.wustl.edu/~schmidt/TAO.html) is a free available Object Request Broker, which has been ported to numerous Operating Systems (including some RTOS). This link is given in reply to the speaker’s request for links to real-time ORB’s. A product family SW development approach, having a common architecture but creating diversification based on component type variations is be interesting for certain application domains dealing with SW for related products. [references to Linda Northrop - Carnegie Mellon] Barco Display Systems Strong points Very elaborated and rigid software development process (V-model) The V-model implies a rigorous test plan Possible tracks for improvement No explicit modelling of real-time constraints. Guaranteeing deadlines is then a process of trial-and-error. Annotating Message Sequence 11 SEESCOA PROJECT BARCO VISIT REPORT Charts with timing information is a first step in modelling these constraints. 12 SEESCOA PROJECT BARCO VISIT REPORT Appendix A: SW Engineering methodologies and tools [pointers opnemen & relevante artikels in bijlage & verantwoording: deze lijst is niet volledig, noch zijn we experten in alle opgesomde links. Het is een market survey die we hebben gedaan en waarvan we denken dat het voor het bedrijf in kwestie nuttige informatie zou kunnen opleveren] [Dit blad dient als frontblad: het is bijgevolg niet genummerd. Na dit blad moeten de copies van artikels/pointers volgen. Let erop dat dit in de TOC geupdate wordt (mag geen nummer hebben)!] SEESCOA PROJECT BARCO VISIT REPORT Appendix B: Debugging methodologies and tools [pointers opnemen & relevante artikels in bijlage & verantwoording: deze lijst is niet volledig, noch zijn we experten in alle opgesomde links. Het is een market survey die we hebben gedaan en waarvan we denken dat het voor het bedrijf in kwestie nuttige informatie zou kunnen opleveren] [Dit blad dient als frontblad: het is bijgevolg (nog) niet genummerd. Na dit blad moeten de copies van artikels/pointers volgend. Let erop dat dit in de TOC geupdate wordt !] SEESCOA PROJECT BARCO VISIT REPORT Appendix C: Real-time Operating Systems [pointers opnemen & relevante artikels in bijlage & verantwoording: deze lijst is niet volledig, noch zijn we experten in alle opgesomde links. Het is een market survey die we hebben gedaan en waarvan we denken dat het voor het bedrijf in kwestie nuttige informatie zou kunnen opleveren] [Dit blad dient als frontblad: het is bijgevolg (nog) niet genummerd. Na dit blad moeten de copies van artikels/pointers volgend. Let erop dat dit in de TOC geupdate wordt !] SEESCOA PROJECT BARCO VISIT REPORT Appendix D: GUI methodologies and tools [pointers opnemen & relevante artikels in bijlage & verantwoording: deze lijst is niet volledig, noch zijn we experten in alle opgesomde links. Het is een market survey die we hebben gedaan en waarvan we denken dat het voor het bedrijf in kwestie nuttige informatie zou kunnen opleveren] [Dit blad dient als frontblad: het is bijgevolg (nog) niet genummerd. Na dit blad moeten de copies van artikels/pointers volgend. Let erop dat dit in de TOC geupdate wordt !]
