Download presentation
Presentation is loading. Please wait.
Published byMarshall Bishop Modified over 6 years ago
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
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.