Current TRL: 3 (11/2/21)

“Emulated Sensors & Individual Sensors Have Been Tested”

SCADA

Supervisory Control And Data Acquisition.

It is a supervisory software that is fully developed by the team. This software is not required by the FSAE rule however it is a tool used by the engineering team to debug the car during the development phase and testing phases.

The main goal of this software is to help the team to detect any anomaly in the car subsystem during testing or driving mode and to help the team to analyze the car performance after the driving for future improvement of the car.

Metrics and Constraints

Metrics:

The SCADA software should be compatible with any desired sensor of the following types: CAN, I2C, GPIO, and USB. This is a design choice by the 2020-2021 team.

The SCADA software should have enough storage space for a single test run. The duration of a single test run has not yet been defined. (Literature Review Reference: “Building a Data Acquisition Architecture for a Formula SAE Racecar)

The SCADA software should have the ability to communicate with any other desired subsystem. (Literature Review Reference: “Design and Implementation of the Software and Hardware System for a Formula SAE Electric Vehicle”)

The SCADA software should have a supervisory control system. The supervisory control system will make changes to the vehicle according to the sensor output data. The functionality of the control system has not yet been scoped. However, the data sampling frequency will be determined by the desired functions of the control system. (Literature Review Reference: Control Strategy and Hardware Loop”)

Constraints:

The Formula Hybrid competition does not have any rules restricting the SCADA software system.

The computing language of the SCADA software system should not restrict the software from running at the desired speed. As mentioned previously, the desired speed has not been defined because the supervisory control system has not been scoped. (Literature Review Reference: “Secrets For Succesful High-Speed Data Acquisition”)

The hardware, specifically the central processing unit, of the SCADA software system should not restrict the software from running at the desired speed. As mentioned previously, the desired speed has not been defined because the supervisory control system has not been scoped. The current hardware is a Rasberry Pi 3.  (Literature Review Reference: “Secrets For Succesful High-Speed Data Acquisition”)

Design Goals:

The first and main goal of the team is to make the SCADA software read sensor input values using CAN, I2C, GPIO, and USB protocol and display them on the CarMan UI so that it can act as a debugging tool for the team. This requires compatibility with these sensor types and communication with the CarMan subsystem.

After this goal is accomplished, the second goal is to improve the sampling frequency of the software. The current SCADA system can only take information at a maximum frequency of 1 Hz and its main use is to debug the car to make sure all the systems are working. In order to improve the current electric vehicle, the SCADA team is looking to improve the data sampling rate of the software.

After the debugging component of the SCADA software is delivered to the club, the goal of this team is to design a system that is capable of taking in data at a higher sampling frequency and displaying it on the GUI. This system will be called FASDAQ, fast data acquisition.

Literature Review  

The FSAE formula electric vehicle is composed of different subsystems working together. The more subsystems the car possesses, the harder it is to detect any anomaly for a specific subsystem. In order to overcome this, the FSAE team needs a supervisory system in order to monitor the car. The data collected can be useful for the technicians and engineers to detect and repair any technical issues.

For that reason, the Lafayette FSAE team decided to develop the SCADA system. SCADA stands for Supervisory Control And Data Acquisition. As the name indicates, it is not a full control system, but rather focuses on the supervisory level. As such, it is a purely software package that is positioned on top of hardware to which it is interfaced, in general via Programmable Logic Controllers (PLCs), or other commercial hardware modules. SCADA systems are used not only in most industrial processes: e.g. steel making, power generation (conventional and nuclear) and distribution, chemistry, but also in some experimental facilities such as nuclear fusion. The literature review provides documentation for the role of the supervisory control component of SCADA.

In addition, the provided literature dives into how to create software of this complexity while also meeting the metrics and constraints outlined. More specifically, it covers how to choose the hardware on which this subsystem will run on. Furthermore, it also covers what type of software should be utilized and how it should be structured to ensure optimization. Moving outside of our metrics and constraints, the SCADA team would like to create software that implements components of control and telemetry. The literature discusses these concepts and how they can be integrated with data acquisition software.

Full Literature Review

Codes and Standards

PTC 19.22

This standard is from the American Society of Mechanical Engineers (ASME). This Code addresses stand-alone data acquisition systems, typified by a sensor with an integral digital display, data acquisition systems that link multiple sensors to a common digital processor tied to a computer , and systems that link multiple digital processes to one or more stand-alone or net-worked computers. It also provides a means to determine the uncertainty associated with the data acquisition system, and its impact on the overall uncertainty of the performance test.

SCADA High-Level Diagram

The previous years SCADA software has been evaluated for the previously defined metrics and constraints:

  • The current SCADA software includes a driver module that allows sensor readings from the desired sensor types: CAN, I2C, GPIO, and USB. This is visible on the left side of the High-Level Diagram.
  • The config file where the sensors are stored allows for sensors to be added and removed given they’re of the previously mentioned type. This config file is labeled, by the diagram, as “config.yaml.” The current sensor is compatible with new sensors of the types listed in the metrics.
  • The SCADA software does not currently store data for individual test runs.
  • The SCADA software currently has the ability to communicate with the CarMan subsystem. This communication is illustrated on the right side of the diagram GUI is delivered to the CarMan display.
  • The supervisory control component of SCADA has not yet been created.

The graphical representation of the higher-level design of the current SCADA software is shown below:

NB: The functions of these different blocks are explained in detail in the following link: here


SCADA High-Level Software Architecture Diagram

SCADA High-Level Hardware Architecture Diagram

  • SCADA Carman GUI

The SCADA GUI is a user interface that will be connected to Carman to visualize different sensor readings in the car. It is placed at the back of the car. The current design of the GUI is as follows:

 

SCADA Carman Display Graphical User Interface

  • SCADA Post Processing

The purpose of the post-processing system is to allow the car team to analyze data after the car has run for a period of time. The Post Processing system is meant to be run on a local computer. The high-level diagram below shows the general overview of the software architecture.

SCADA Post Processing Software Architecture Diagram

It records the data such as the duration of the car travel during a specific date as well as the sensor reading history.

TRL Chart

TRL What does this look like? Expected Completion Date
9 Competition Ready TBD
8 Metzgar High-Speed Test TBD
7 Rolling Chassis Test — low-speed data collection in a semi-relevant environment (Metzgar/AEC parking lot) TBD
6 Integrated Car Static Test — Collecting Data relevant subsystems while at rest TBD
5 SCADA has been tested in DYNO/AEC 134 w/Individual Subsystems 12/10/21
4 Integrated Rig Tests With Multiple Sensor Inputs 11/12/21
3 Emulated Sensors & Individual Sensors Have Been Tested COMPLETED
2 Hardware & Software Selection COMPLETED
1 The purpose of the system has been identified COMPLETED

 

User and Maintenance Manuals 

SCADA_2021 User Manual (PDF)

SCADA_2021 Maintenance Manual (PDF)

SCADA Installation Instructions (PDF)

Errata 2021

SCADA Errata (PDF)

Poster 2021

SCADA-2021 Poster (PDF)

Additional  Documentation

  •  SCADA Design Review I: Here 
  • 2020-2021 Source Repository: Here