Modeling Methodology for Adaptive Systems with MATLAB/Simulink
Adaptive systems face a plethora of complex scenarios to be accounted for
The development of CESs/CSGs requires a well-founded approach for dealing with a number of difficulties that result from the high complexity of the scenarios involved and that have to be incorporated. For instance, an autonomous fleet of robots must react to dynamic changes in the policy of the manufacturing execution system (MES), or the number and nature of its members, in such a way that the overall functionality and efficiency of the CSG is safeguarded. To give an example, the virtual exploration of strategies to address different
goals is essential to improve a system’s efficiency, cf. Section 9.2. In this context, the consistent application of a model-based development process for CESs offers a variety of benefits, such as early and systematic validation of functional requirements that describe the CSG/CES behavior. Different engineering solutions can be based on suitable system model variants that are validated and compared in a fully or partly virtual context. Moreover, Simulink models can interface with typical robot middleware or communication frameworks, such as the Robot Operating System (ROS). For instance, Simulink models may define ROS nodes or generate standalone ROS nodes based on C++ for use in an ROS network.
Need for tailored tool chains
The model-based approach greatly benefits from tailored tool chains, which automate a large number of development activities,including requirements management, modeling and simulation, as well as integrated quality assurance. For instance, in the case of the fleet of robots, the monitoring of the distribution process for incoming tasks can be automatically included in the Simulink model. The virtual representation provides a sound foundation for developing, maintaining, and extending the actual system and its hardware/software/mechanical components efficiently.
Using Simulink
With regard to the model notation, the domain-independent language Simulink is suitable for describing the functional behavior of the CSG and the CESs as well as their context. In the case of a fleet of robots, the manufacturing execution system broadcasts different global goals dynamically to the fleet of robots. Typically, the global goals define a trade-off between the following competing objectives:
1. Economy: Minimize the total distance driven by all CESs — i.e., the transport robots.
2. Robustness: Keep the job queue lengths of each robot as short as possible.
3. Performance: Maximize the number of jobs executed per time unit.
4. Maintenance: Distribute the tasks such that all robots drive a similar distance.
As mentioned in the preceding paragraphs, KPIs are used to represent the goals in a measurable way. A suitable collaboration strategy for the collaborative robot fleet members must be designed corresponding to the given goals, cf. Sections 9.2 and 9.3. Therefore, the fundamental part of the modeling is dedicated to the distribution of the incoming transport jobs depending on the dynamically changing objectives. The collaborative fleet of robots consists of a finite number of robots that redundantly control and maintain the required data structures, such as job queues, distances driven, and their batteries’ states of charge. Based on this data, a bidding process determines the collaborative robot fleet member with the lowest job execution cost. The global goals are encoded using a suitable bidding parameter vector. The context model, which represents the highest level in the hierarchy of system models, describes the interaction of the transport robot with its environment — for example, the manufacturing execution system. Furthermore, a suitable transport robot architecture that is capable of addressing adaptivity can be introduced based on a hierarchical decomposition. This approach yields a decomposition-type model that defines each transport robot’s components and interfaces. Most notably, the collaborative AGV controller (CAC) hosts the logic for calculating the bidding values based on the current system state and goals. Correspondingly, each CAC model consists of the following:
-
A reconfiguration unit, which is triggered whenever a new transport job is published or the collaborative robot fleet constituents are altered
-
A processing unit for the transport robot goals — that is, bidding values for the autonomous task distribution are computed from the CAC data, as well as from the bidding parameters associated with the currently active transport robot goal and the member- specific local goals (e.g., maintaining a minimum battery level)
-
A bidding unit that determines which robot receives the published task
-
A unit that holds and updates the CAC data (battery level, path lengths, etc.)
-
Units that manage the interface with ROS to determine path lengths and battery states
Figure 9-9 shows the resulting components in the system decomposition model. The system behavior is fully composed from the behavior models of each component. These component-related behavioral models represent the third level in the hierarchy of system models.
Capturing MES policies in the requirements
The expected adaptive system response, which is subject to dynamically varying manufacturing execution system policies, must be fully captured in the requirements of the fleet of robots. Compared to natural language-based approaches, which are still widely used in practice, formalized requirement formats give rise to unambiguous representations of requirements of the fleet of robots. Moreover, with the model-based approach, formalized requirement formats can be fully integrated in the sense that state-based or event-based triggers and the required signal response can be fully defined using references to model entities, such as signal specifications or design parameters. In conjunction with the efficient definition of appropriate test cases, virtual validation of adaptive CSG behavior can be automated based on automatic test execution and assessment. The assessment relies on the comparison of the logged output signals of the executable Simulink CSG model with the expected output signals as defined in the formalized requirement.
