• Keine Ergebnisse gefunden

Decomposition of Final System and Revision of the Hypothesis 72

5.3 Intermediate Summary: The Final Hypothesis Test Cycle

5.3.5 Decomposition of Final System and Revision of the Hypothesis 72

ideas and new systems is open. On the one hand, decomposition of the implemen-tation is useful for making well-working subsystems available to be used in other systems. Also, individual algorithms can be optimized or substitutes can be tested in the context of a full, integrated system, with the possibility for realistic data collection, full sensory-motor coupling etc.

On the other hand, the fact that the system is reflected in a formal design eases the development of variations of the original hypothesis, for instance, to stay with the AutoSys example, by accepting that a valuable preprocessing was achieved which can be integrated into future systems, and focusing on the next interesting challenges such as scene prediction or behavior learning.

5.4 Conclusion

This chapter has addressed the essential problem of bringing a theoretical System-atica 2ddesign to a practical, running system on a given software infrastructure.

On the examples of popular software infrastructures for intelligent systems we pre-sented how the technical language elements of Systematica 2dcan be mapped to the concepts of each infrastructure and thus illustrated how a theoretical design can be turned into practice. The elements of aSys2ddesign which are relevant for this mapping are units, connections and input roles. These were shown to match main concepts of many software infrastructure paradigms, with a focus on service-oriented (Player[24] and Microsoft Robotics Studio[14]), blackboard-oriented (XCF[22] and CAST[23]) and dataflow-based (YARP[20], ROS[18] and ToolBOS[25]) infrastruc-tures. Thus, this mapping provides a straightforward way of translating the technical elements of aSys2ddesign into a structure for system implementation.

One exception is the ability of a software infrastructure to provide means for re-liable modulation, which we found to be present only in blackboard-oriented infras-tructures. We therefore formulated a generic and practical method to handle loosely coupled inputs (i. e. DrivingOptional and Modulatory) so that these can be used also on the other software infrastructures. As a second example of such generic system elements, a system monitoring concept, based on the concepts of reliable modulation and the formalSys2dproperty of incremental construction, was introduced.

Finally, in an intermediate summary of the previous chapters, both the mapping and the generic elements were put into the context of the completed hypothesis test

5.4. Conclusion

cycle to bridge the gap between theoretical hypothesis formulation and practical sys-tem construction. Given this improved process for the hypothesis test cycle resulting in formal designs on the one hand and in practical, measurable systems on the other hand, the following chapter will look closer at the properties and types of these sys-tems and thereby attempt a first step towards understanding the space of possible systems.

6 System Properties and Types

Designs in Systematica 2d are characterized by the set of units U, including its two-dimensional ordering, and the additional description given by the set of sub-architectures A. So far, in terms of system implementation and evaluation, only the technical aspects of U, especially interfaces, dependencies and the ability for incremental construction (which is related to the order of units) were relevant. In this chapter we will discuss the meaning of sensor and behavior spaces, as specified in each sub-architectureak ∈A,ak =(name,Uk,Sk,Bk), as well as the meaning of the global two-dimensional pattern of units and what can be deduced about the

‘type’ of design it expresses.

This discussion follows a set of global system properties and is based on the set of

‘architecture properties’ introduced by Goerick in [5]. These properties are discussed from scratch in the two-dimensional world ofSystematica 2d, where especially the layout of units allows more quantitative statements for the analysis of sensor and behavior spaces than the one-dimensional description ofSystematica.

Three system properties will be discussed in this chapter:

1. The sensor and behavior spaces must be defined in terms of their qualitative meaning for system description (why they should be described) and their prac-tical interpretation in the system design (which design elements are responsible for implementing these spaces).

2. The question whether sensors are used to form incremental representations is important to distinguish the mentioned ‘types’ of design.

3. An analysis of sensor and behavior spaces and corresponding units will show the degree ofsensory and behavioral confinement of each sub-architecture.

The introduction of these properties in Sec. 6.1 will provide a tool set which is then used to propose a non-exhaustive set of ‘design types’ in Sec. 6.2, including an overview of benefits and drawbacks and where existing systems fit into these.

Chapter 6. System Properties and Types

6.1 System Properties

The properties discussed in this section create a relation between the technical, implementation-oriented features of theSystematica 2dunits u1..uN and the de-scriptive sub-architecturesa1..aM, especially the sensor spacesS1..SM and behavior spacesB1..BM. The fact that units and sub-architectures are specified separately in any givenSystematica 2d design may be understood to imply that there is no direct connection between the two, but since all actual behavior of the full system stems from the implementation, ergo from the units, there ultimately is some form of redundancy in this description. The Systematica 2d language does not make as-sumptions about the order in which design elements are specified, but we find it much more likely that the description of sub-architectures follows the description of units (or vice versa) than that both are independently and separately developed. Thus, it is legitimate to ask how unit interfaces, dependencies and two-dimensional order correlate with the sensor and behavior spaces, as well as with their interpretation in terms of incremental representations and confinement.