M&CML: A Monitoring & Control Specification Modeling Language

1. M&CML: A Monitoring & Control Specification Modeling Language PuneetPatwari, SubhrojyotiC , G Muralikrishna, N.Swaminathan Systems Research Lab

2. Agenda • Background of Monitoring and Control Architecture • Motivation for Domain Specific Language (DSL) • Realizing M&C responsibilities • Possible Implementation Approaches • Approach to DSL • M&CML concepts and Features • M&CML Framework Architecture • Case Study • Conclusion

3. Background of Monitoring & Control Architecture • Large Scientific Projects composes various systems. E.g., Antenna, correlator for Radio Telescopes and Power, Magnet for Nuclear Fusion reactors etc. • Role of Supervisory Control • Co-ordinate to achieve the overall goal. • Monitors systems and subsystems. • Development of Supervisory Control • Requires sub systems to work out M&C requirements independently. • Agreement on control responsibilities is done subsequently. Supervisory Control Interface control documents (ICD) S1 S3 e.g., Power system S2 e.g., Cooling tower e.g., Antenna SysML for M&C designs

4. Motivation Amount of Control Functionalities visible and explicated? Large Scientific Projects Overall Control architecture and the interfaces? Clean handover of M&C design specs to subsequent phases? Standard Design Modeling technique followed System Modeling Language (SysML) Partial Integrated models Design specs exchanged among various groups? Standard Vocabulary or glossary? Designing Control Functionality like Alarm Handling/Data Processing in models, are they specified?

5. Realizing M&C Responsibilities The most widely and dependable means today are creating ICDs We need something to alleviate the shortcomings!! • Pros: • Defines Interfaces and control items that flow through it. E.g., Commands, data points, message, alarms, events • Provision for agreeing on control responsibilities. E.g., Statemachine, Command validation, event/alarm handling • Cons: • Fails to provide a holistic view of control architecture. • No scope for actual implementation of integration of controllers. • Need for supporting mechanisms to translate ICD into implementation-specific format. Interface Control Documents

6. Implementation Approaches Zero Level Writing Integration Code Manually SysML, ICDs input • Writing Integration Code • Delegate to responsible parties the task of writing implementation code. • Challenges • Results in a lot of effort to create code for all interfaces. • Painful to maintain since each group will implement independently. Next Level Populating Templates Templates input • Creating Templates For Integration • Useful in capturing control concepts, functionality and interface data in a standard format like XML. • Used to create one off tools with user interfaces to produce specification files. E.g., SACE model • Code generators translates information into integration code.

7. Example of SACE specification approach Specification-driven but requires multiple type of spec formats Current practice for writing M&C specification involves minimum use of three technologies, for example, XML files to specify control items, Excel sheet to write rules, JAVA for implementation and other technology to design behavioral concepts like statemachine etc. With M&CML only one file will be sufficient to specify everything thereby saving a lot of time n space.

8. Our Proposal – An approach based on Domain Specific Engineering We need a Domain Specific User Interface for a domain specific model - Domain Specific Language(DSL) seems the right option We Created a DSL platform – Monitoring and Control Modeling Language

9. Approach to DSL View any system that requires to be controlled through a ‘Control Lens’ • Identify concepts and keywords for M&C domain. • Identify structures and functions. • Understand the existence of other lenses (security, stakeholder etc.) and establish relationship among them. For M&CML two foundational aspects can be viewed from the control lens output input • The Interface description capturing details using M&C concepts . • The Control Node capturing required behavior and functionality of a controller.

10. M&CML Concepts & Features • Features • Associated Viewpoint Domain-Intelligence, • Third party support by means of Code Generation, • Verifiability using Syntax and domain specific validations and static analysis, • Source code navigation, • User Assistance with the help of Code Completion and template support, • Concepts • Control Node, • Commands, • Alarms, • Events, • States, • State Machine, • Alarm Handling, • Data Points, • Data Handling, etc. M&CML Built-in Provides

11. Example 1. Spec file for Servo System control items 2. Security aspect for Servo System controls Refer to servo system Refer to Alarm A1,A2 of Servo System

12. M&CML Framework Architecture • M&CML follows Model – driven approach. • Ecore Meta-model specific to domain is created using Eclipse Modeling Framework (EMF) tools. • Language framework created using XText . • XText provides editor to develop domain specific model/configuration files. • Third party support using XText Code generators/Interpreters constructs.

13. Case Study - Analysis Analyses based on comparison with SACE model :- • Use of Four specification formats compared to only One unified language in M&CML. • Possibility of Human errors in SACE. A cause for loss of uniformity and information. M&CML enforces zero errors. Command constructs mismatch in same file State constructs mismatch Current practice for writing M&C specification involves minimum use of three technologies, for example, XML files to specify control items, Excel sheet to write rules, JAVA for implementation and other technology to design behavioral concepts like statemachine etc. With M&CML only one file will be sufficient to specify everything thereby saving a lot of time n space.

14. Case Study - Analyses • M&CML enforces consistency checks which was not possible with our previous approach. Error notification if command specified for translation logic mismatch with child command Current practice for writing M&C specification involves minimum use of three technologies, for example, XML files to specify control items, Excel sheet to write rules, JAVA for implementation and other technology to design behavioral concepts like statemachine etc. With M&CML only one file will be sufficient to specify everything thereby saving a lot of time n space.

15. Conclusion • It is challenging to maintain consistency in the current approach to M&C design. • Based on similarity across various projects, it looks ideal to propose a solution at domain level. • Approach to create a DSL for M&C involves viewing a system through lenses of various domains. • M&CML provides a standard vocabulary and makes the entire process of M&C solution creation domain-aware. • The solution created using M&CML provides a holistic view of control architecture. • M&CML has support for inherent consistency checks, user assistance and third party support. • The future direction is to validate the language in context of large projects such as SKA. Current practice for writing M&C specification involves minimum use of three technologies, for example, XML files to specify control items, Excel sheet to write rules, JAVA for implementation and other technology to design behavioral concepts like statemachine etc. With M&CML only one file will be sufficient to specify everything thereby saving a lot of time n space.

16. THANK YOU…