PRODUCT LINE PARADIGM FOR ROBOTIC SYSTEM SOFTWARE

Software systems, like physical systems, require explicit architectural descriptions to increase system level comprehension. Developing networked robotic systems of diverse physical assets is a continuing challenge to developers. Problems often multiply when adding new hardware/software artifacts or when reconfiguring existing systems. This work describes a method to create reconfigurable software for Army robotic systems via model-based, graphical domain-specific languages and reusable components. The paradigm makes use of feature models, the basis for product line software that describes and constrains variable aspects of the robotic system’s hardware and associated software. Domain-specific languages use terms understandable to domain engineers and technicians. Users of the modeling environment are able to stay at a high level of abstraction and need not concern themselves with the details of the composed and generated code. INTRODUCTION “Robotics” is a word that infers different meanings to different people, and also to the same person at different times. In this paper we will use the word “robotics” abstractly to infer to a collection of activities necessary to create a useful robot. These activities encompass the entire life cycle of the robot. The collection of activities can be highly structured, structured within a specific phase, ad-hoc or any combination of above. Structured activities are the basis of Systems Engineering. The Product Line Paradigm provides a framework for a set of interconnected structured activities across the life cycle. Robots, as many other modern devices are collections of embedded systems. Today’s cars, trucks and construction equipment are also collections of embedded systems. Most modern automobiles have 20 to 70 electronic control units with 100 to 1000 million object code instructions. 1 Software provides much of the value added to the devices we use day to day, with some estimates of 80% or more in the automotive industry. If we consider commercial vehicles as a starting point, we can see that the number of software instructions can be immense as seen in Figure 1: System Size vs Deployment (after 1). Aircraft navigation systems are another good example of a baseline system that requires large efforts for on-board software development, as well as ground support systems. If we consider a commercial air platform as our baseline, we begin to understand the problem of adding specific mission package software. If we consider a commercial truck as our base platform, we may argue that the problem is of an even greater magnitude. There is no existing ground support structure for autonomous vehicles, while airplanes enjoy a “little airplane, big sky” environment. Autonomous ground vehicles are required to operate in a dynamic, cluttered environment. Figure 1: System Size vs Deployment (after 1) The cost of building effective embedded software is not directly related to the number of units produced. It takes approximately the same effort to produce software for a single system as it does for a fleet. Robotics has all the issues that current commercial systems have. Safety is of course a major concern, since the human is not the prime Proceedings of the 2009 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS) PRODUCT LINE PARADIGM FOR ROBOTIC SYSTEM SOFTWARE, W. Smuda, PhD, et al. Page 2 of 8 controller. Reliability, security, computational resources and heterogeneity, as well as real-time concerns all also play a large role. Furthermore, robotic system may be modified over time, particularly in military systems. The software needs to be accessible and understandable. Department of Defense (DoD) robotics practitioners are involved at every stage of the lifecycle from concept to use to repair and upgrades. As noted earlier, robotics is a collection of activities. Ad-hoc development is both expensive and time consuming. Vendor internal procedures are not always well known. In order for DoD robotics practitioners to provide maximum value to the taxpayer, a structured systems engineering approach is necessary. Although this paper focuses on robotic software, we will also touch on other aspects where they are relevant. The approach we suggest is the Product Line paradigm. Product Lines Product Lines are a familiar concept for consumer products. They are often used to describe a base platform and available options. Usually, consumers use product line descriptions to buy a car or electronics component with the features they desire. Manufactures use product lines to allow consumer choice at reasonable cost by introducing common components into multiple product lines. Feature Models Product lines are succinctly defied using feature models. This modeling technique, introduced about two decades ago 2 , has both a graphical notation 4 and a textual notation with associated grammar 3 . Designers need to be cognizant of how features are related and of where new features should appear. At domain analysis time, analysts create a feature model. It is a tool for domain analysis to communicate information between developers and users and, if preserved, a temporal tool to determine what the original developers were thinking during a previous spiral. Feature models present software developers with a tool, much like an assembly diagram for a mechanical developer. As Czarnecki and Eisenecker state in their chapter on feature modeling in their book, Generative Programming 4 , “Feature Models provide an abstract, concise and explicit representation of the variability present in the software.” One should note that the feature model, like the assembly drawing, is not a full representation of the system; it combines with other models for full system representation. A software feature model may have other diagrams and analysis, such as timing constraints, state transition diagrams and object diagrams. The standard example of a feature model is a representation of a car (Figure 2): Mandatory features: engine and transmission Optional features: sunroof Alternate features: manual or automatic transmission and Or-Features: Electric motor, an internal combustion engine or both (hybrid). Features are the building blocks used to describe concepts. Features are configurable reusable requirements of a concept. The feature modeling process is a study of variability in domain concepts. The process is continuous and iterative, involving identifying as many Use cases, existing feature models, system requirements and additional UML models as possible to identify potential variability points. It also involves recording all supporting information as features become available to the concept. Addressing variability is a key issue in creating reusable software. Decomposition decisions that address the variability discovered in feature modeling result in software with a high level of reusability. The feature model is the foundation of the product line paradigm 5 . Formalized feature models can automate segments of the prototyping process. Annotating features Figure 2: Feature Diagram for a CAR Car Engine Transmission Sunroof