The ProMARTES framework targets the DSE of Component-Based Real-Time Distributed Systems (CB-RTDS) and consists of four individual phases: Profiling and Modeling, Architecture Composition, Performance Analysis and Architecture Optimization.
ProMARTES framework is consisted of four individual phases: Profiling and resource modeling, Architecture composition, Performance analysis and Automated architecture optimization. Phase 1: A component developer profiles the SW components and composes resource models for each individual component. The generated resource models are placed into a component repository, along with the developed components and are used in the subsequent design and analysis phase for the performance analysis of the composed system model. Phase 2: At this phase, a system architect selects the required SW components from the repository, and instantiates and connects them to dfine system execution scenarios based on functional requirements. In parallel, an architect composes a HW execution platform and maps the SW component instances onto the HW platform, thereby defining the system model. At this phase, an architect can define multiple architecture alternatives,by varying SW/HW components and their mapping. Phase 3: The composed system model is analyzed for its performance properties. The system is evaluated for specific performance metrics such as: worst-case and average-case execution times of end-to-end execution scenarios, resource utilization, throughput and system robustness. The proposed performance evaluation utilizes a dual performance analysis approach: schedulability and simulation-based analysis. The combination of the previous two analyses types enables a wide range of performance analysis capabilities. Hence, such a combined approach will offer a more exhaustive and reliable system performance evaluation for any serious architecture alternative. Phase 4: This phase aims at identification of the Pareto-optimal architecture alternatives that fulfill the system requirements. First, the predicted performance metrics of each alternative are converted to the system objectives (cost, timeliness, robustness). Then, each alternative is evaluated for its system objectives to identify whether the alternative can included in the Pareto-optimal solution set. The obtained alternatives for a design space are analyzed for certain optimization criteria. If the Pareto-optimal solution set is formed (optimization criteria), the optimization iterations can be halted. Otherwise, another optimization iteration is triggered, starting from the Architecture Composition phase, where our alternative generation algorithm constructs a new set of alternatives automatically. These alternatives are applied to performance analysis and the obtained performance metrics are used at the Architecture Optimization phase. This iterative process runs until the optimization criteria are satisfied.
The ProMARTES toolkit is composed of a number of tools that are available as open source at: https://bitbucket.org/ktriantafyllidis/optimization