1. FESA evolution and the vision for Front-End Software
Frédéric Hoguin
19/10/2017

2. FESA mandate
Provide a comprehensive development environment to design, develop, and test real-time software for FECs
Define a generic model that captures the recurrent aspects of real- time software programming in the domain of accelerator control
Define a method whereby equipment specialists reuse and reapply the generic architecture and tailor it to their specific needs on a case- by-case basis
Provide a set of software tools to support equipment specialists, users and the exploitation team at all stages of development and operation

3. FESA mandate summary Comprehensive FEC development environment
Model for real-time software programming
Framework runtime and libraries
Debugging tools
Development tools

4. Background FESA has 3 parts: framework, editors, navigator Framework:
Runtime (C++ code)
Code generation (Mostly python code)
Model (XSD + rules)
Editors: eclipse plug-in, CLI, web editor (CCS, CCDE upcoming)
Navigator: diagnostics and tests

5. Timeline 2017: most critical runtime features implemented
2013: stabilisation, version 1.0.0
2014: code generation modernisation, plug-in refactoring
2017: most critical runtime features implemented

6. FESA mandate
Comprehensive FEC development environment Model for real-time software programming Framework runtime and libraries Debugging tool Development tools s

7. Usability

8. Vision: usability FESA IDE (Integrated Development Environment)
Comprehensive (install it, start using it)
Intuitive and easy to use
Eclipse
FESA plug-in
C++ editor
Terminal with SSH to FEC
FESA
Navigator
Eclipse
FESA IDE
Integrated FEC terminal
Eclipse Debugger
Improved editor
Command line
debugger
FESA
Navigator

9. Usability: why? FESA development workflow
Class design
(XML)
C++
Compile
Class library
Generate
XML
Deploy-unit
(XML)
C++
Compile
Generate
Executable
Instance
(XML)
XML
schema

10. Usability: why? FESA development workflow
Eclipse
Visual Studio
LabView Icon

11. Usability: why? FESA editor

12. Usability: why? FESA editor
Excel file editing in XML mode
Excel file editing in Excel mode

13. Usability: why? FESA editor
Equipment groups develop tools to overcome the shortcomings of the FESA editor

14. Usability: why? Unnecessary complexity Steep learning curve
Knowledge of FESA internals required
Knowledge of FEC infrastructure required
FESA editor is too basic and not adapted
Equipment groups develop tools to overcome these shortcomings

15. Reusability

16. Vision: FESA reusability
Composition: use existing FESA classes to create a new system which combines these classes
Inheritance: adapt, replace, and extend the behaviour of existing FESA classes
MyFeedback
OasisScope
CGDIO

17. Vision: FESA Reusability
FESA Class
Inputs
Outputs
Events
Actions

18. Reusability: why? Saves time Reduces code duplication
Reduces technical debt
Improves code quality

19. Integration

20. Background Different frameworks populate the CERN controls ecosystem
FESA, FGC, WinCC, Virtual devices, …
They were developed separately, with integration as an afterthought

21. Other services with their models
Integration: why?
FESA
CCDB
LSA
DB model
DB model
FGC
LASER
DB model
Other services with their models
Other
= 6+$+M

22. Integration: why? OASIS GUI OASIS application server
OASIS data source interface
OASISAcquisition property
FESA RF Class with signals
FGCD signals
Other signals sources

23. Integration: summary
The device/property model is implemented in several different ways across different frameworks
Bad compatibility, n×m “moulinettes”…
Hinders evolution of our model (any change has a high impact)
Evolutions made without consensus: hard to know which frameworks supports which features
Synchronization issues between our services
Rules must be followed, but are not enforced
New FW feature
CCDB FW specific handler
Application FW-specific code
Apply “temporary” fix
Technical debt increased No
Remove fix?
Yes (1)
Breakage No
Yes (2)
Problem fixed?
Wait a few months
Yes
It still works!

24. Vision: Integration
Unified device/property model, that decouples interfaces from implementations
A single, reference implementation of a device server, shared by everybody
Script
GUI
Device
Interface
Interfaces
database
CERN device server
Private
database
FESA
FGC
WinCC
Virtual
devices
Other…

25. CO3 task force: integration
In collaboration with interested groups (CO, EPC, STI, ICS, MPE):
Design a common device/property model that can be used in all layers, that decouples interfaces from implementations.
Provide a reference implementation of the device/property server, with bindings to different languages.
Provide a language-agnostic API that allows clients to retrieve interfaces to devices.
Enforce rules throughout the control system based on this model.

26. CO3 task force status
Today