How to Perform a Control Systems Project: The Example of BBCS
PROJECT APPROVAL, YAY!
After years of waiting, your new big science project has been approved, with the initial design papers long obsolete. Regardless of whether you shall be developing the control system entirely in-house or also using the assistance of a specialised engineering company, you now face serious challenges.
Project Flow
While the scientific goals and operational parameters of big science machines are fairly well-known from the project inception, the means of achieving those goals change naturally as part of the design and development process. The control system (CS) is tightly and vertically integrated with all machine elements, and the requirements may vary continuously during the project.
MAJOR COMPONENTS OF THE MACHINE
For the narration at hand, let us look at the example of a sizeable particle-accelerator project. Simplified, the significant components of the machine are:
- Timing System,
- Machine Protection System (MPS),
- Control Room,
- High-level Applications,
- Data Management System,
- Control System Services,
- Development Environment,
- Control Equipment Catalogue,
- Control Box(es)
(or a differently-named standard/template hardware/software platform), - Integration Support and
- Collaborative Infrastructure & Services.
As controls people, we have developed an engineering and quality assurance process for delivering a control system that addresses the issues above, tying together all the major components. We call the process Building Blueprint-based Control Systems (BBCS). It includes the complete management of the control system development, integration and commissioning together with a set of Standard Operating Procedures (SOPs) that make any quality -standard compliance or possible certification down the road more manageable.
Top-level Engineering Process
INITIAL STAGES
First, the managers and the controls team formulate the initial stages of the project, focusing on proposed activities with reasons and the primary benefits to the customer (internal or external), such as
- Risk reduction,
- Timeline of quality-assessed deliveries and
- Smooth transfer of ownership.
Our team explicitly addresses how it will deal with changing requirements. The first significant part of the project also consists of a detailed technical study. The team prepares a complete set of project documents aided by the following activities:
- Gathering,
- Defining the requirements (with iteration),
- Creating system specifications,
- Performing a conceptual and detailed design and
- Defining all interfaces to the external systems.
The in-depth study’s primary purpose is to address a set of challenging questions so that hidden costs and surprises do not surface later during project fulfilment. We fully account for the system components’ Requirement changes in the Risk Mitigation Plan, which is part of the Final Design.
WORK BREAKDOWN
If the team works for an external customer, it can generate an offer for either fixed-price work or incremental phase-oriented work based on the detailed study. In case of a fixed-price contract, the team assumes responsibility and authority to deliver the complete control system, on time, conforming to the necessary quality standards.
Work Items and Project Tasks
The output of the Detailed Study phase, to be accepted in a formal gate-review meeting, is a set of documents that define:
- a “Design v1.0” document,
- a Cost Build-Up (CBU) that lists all work items needed,
- a project plan that states staffing,
- the timeline for the CBU items and
- a fixed-cost evaluation statement.
CONTINGENCIES
During the Project Execution phase, requirement changes are part of the engineering process, and we also handle them iteratively. In compliance with the Risk Mitigation Plan, the team ads the contingencies from the Project Execution phase to the project plan.
Using a Blueprint Control System, the benefits of using SOPS and tested technologies and solutions for all parts of the control system, thus avoiding the traps of under- and over-engineering which frequently occur in “from-scratch” projects.
Overengineering can appear to raise quality in parts of the project, but increases complexity in adjacent sections, inflating costs and prolonging lead times.
CONCLUSION
Over the last two decades, computer hardware and software has developed rapidly. It is now increasingly easier to obtain many of the required technical solutions for a big science control system off-the-shelf, reducing the need for custom development, and employing an efficient engineering and quality assurance process, such as BBCS. The latter decreases development effort and significantly reduces lead times which, in essence, is the dream of scientific project managers all around the world.
ABOUT THE AUTHOR
Rok Šabjan is the Technical Advisor and Sales Director for the Scientific domain at Cosylab and is also one of the company’s co-founders. He was a Java and EPICS developer for many years, followed by being a project manager and group leader. In the last decade, he focused on key account management and business development. Rok was also appointed Cosylab executive board member in 2020.