| Current Path : /var/www/web-klick.de/dsh/11_kistler/tssproj/ |
Linux ift1.ift-informatik.de 5.4.0-216-generic #236-Ubuntu SMP Fri Apr 11 19:53:21 UTC 2025 x86_64 |
| Current File : /var/www/web-klick.de/dsh/11_kistler/tssproj/document_ift.md |
---
pageheight: 297mm
pagewidth: 210mm
marginleft: 17mm
marginright: 14mm
margintop: 16mm
marginbottom: 57mm
pagefooter: 268mm
pdfdpi: 300dpi
---
<style type="text/css">
* { font-family: Arial; font-size: 19px; line-height: 1.7em }
div.header { font-family: Arial; font-size: 50px; font-weight: bold; color: #0094DF }
text.absender { color: black; font-size: 12px; text-decoration: underline; }
text.address { color: black; font-size: 23px; }
text.ort { color: black; font-size: 23px; text-decoration: underline; }
text.person { color: black; font-size: 16px; }
text.email { color: black; font-size: 13px; }
h1 { color: black; font-size: 28px; }
h2 { color: black; font-size: 25px; }
</style>
<p class="break"/><!-- div class="header">...</div-->
Test Stand Software - New Architecture
======================================
<br/>
<br/>
1. General architecture
=========================
A new generation for the RnD teststands at Kistler company shall include:
- A modern 3-layer architecture (Backend, Middleware, Frontend)
- Including all measuring and steering facilities in the existing software
- Extended configuration facilities for the end-user for
a) Measuring processes
b) Parameter value set consistency checks
c) Reporting section
- Modularity
- Maintainable
The general architecture is described in the graphics [img1]
<img align="center" src="img1.jpg" width="800" description/>
1.1. GUI
----------
The GUI of the TSS shall contain the following elements:
- User administration
- Configuration of the test stand
- Configuration of the test object
- Configuration of the test process (sequencer)
- Consistency check
- Control of test runs
- Reporting section
Each of that sections correspond to a certain screen of the TSS GUI [img2]
<br/>
The technology for the GUI programming is Python/Qt (temporarily).
As soon as the Kistler SkyBase framework is available, the GUI technology shall
be switched to that.
The connection form the frontend to the Middleware is done directly by liabray calls.
As soon the SkyBase framework is available, the Python/Qt will be replaced by SkyBase.
The connection to SkyBase will be via a certain Webserver.
1.2. Middleware
-----------------
The middleware is written in Python, data serialization and persistence is done
with builtin JSON and SQLite. The SQL statements are done in a manner that it
can also easily connect to a MySQL-Database.
The functions and controls shown in the GUI are connected to functionality in the middleware.
The middleware contains:
- data storage for the user administration
- data storage for the configuration of the test stand
- data storage for the configuration of the test objects
- data storage of the sequences constructed in the GUI
- data storage of the runtime data of the sequences
- a connection to the backend via OPC-UA data access / events
The connection from the middleware to the backend (see below) shall be done
with KiConnect. As long KiConnect is not available, the connection
is replaced by OPC-UA.
In Python there is a free complete OPC-UA stack which can connect to the
backend via data access and events.
1.3. OPCUA / KiConnect
------------------------
For the connection from the middleware to the backend we have to have a communication
technology. For that we use OPC-UA. KiConnect also is to be supposed to use
the same API, so that the pure OPC-UA easily can be switched to KiConnect.
There are two methods being used in the middleware:
- Data access. It is used to control the parameters for the test stand, the test objects
and general configuration data of the test stand.
- Events. The events are used to send measuring data just in time to the middleware
to show data directly and online.
The events are not implemented yet. The data access is a requirement to the backend and
is built in partially (setting voltage values for the test stand motors).
The techniques to connect with data access / events from Python client (middleware) to
CPP (backend) are realized in code and tested.
1.4. Backend
--------------
For the backend it was planned to use the old code of the test stand software, applying
a certain API, which is able to run the built-in checks by controling it from the level
of the middleware.
During the work, it became apparent, that this plan is not able to get into realization.
The reasons for that have been:
- The old software is divided in a lot of branches for every customer. It is not clear
which branch shall be representative and being taken into the set of API functionality.
- The checks in the old software are tied to variable settings which are hard-coded
in different modules of the software. It was obviously not possible to separate
the meanings and depedencies of that variable settings.
- Some of the checks are highliy intergrated, complex checks with a lot of variables
(especially the checks S1, S2, S3, S6). It makes no sense to provide an abstract
approach to that checks.
For this reason, in the project the decision was made to start from the scratch in the backend.
It was planned to provide OPC-UA interfaces to all of the hardware components step by step.
Until the end of the project it was realized:
- A voltage control of test stand motor.
- A CAN Bus test interface.
<p style="page-break-before: always;"></p></br>
<p class="break"/><!-- div class="header">...</div-->
2. Graphical User Interface
==============================
It follows the description of the elements of the graphical user interface
<br/>
2.1. User administration
------------------------
The user administration distinguishes two kinds of users:
- Administrator
- Normal user
An administrator is allowed to access to all areas of the software,
even creating new users (administrator and normal user), and granting
access rights.
A normal user has limited access to the areas of the software.
He shall not be allowed to create new users and grant access.
A detailed list of the allowed areas for administrator and normal user
is given in the table [tab1]
... [tab1] ...
In the software there is a global variable which contains the name
of the current user. A user table (in form of a text file) contains
the assignment of a user to be adminitsrator / user.
The table with the access rights is hard-coded in the file
core/config.py.
<br/>
2.2. XML Configurator
-----------------------
The configuration of the teststand consists of three elements:
- the parameters of the test stand
- the parameters of the test object
- general parameters of the test procedures
To make the configuration straightforward and easy, we choosed to define
the configuration in an XML file which can be easily edited with
an XML editor (recommended: Altova).
The XSD-definition of this XML-File is not yet ready-made and has to be worked out
in detail. It is important that this XSD-definition respects the three parts
of configuration.
The XML-file is read at several stages in the running program:
- at program start (the test stand configuration will be read in)
- when the test object is to be defined
- when general test parameters are to be defined.
The disadavantage of using an external XML-editor is: No interactive changes are possible
here. So in a next version of the software there should be an integrated XML-Editor
in the GUI.
<br/>
2.2. Graphical Sequencer
--------------------------
A main part of the GUI is a *graphical sequencer*.
This is a graphical configuration facility to define test procedures.
The idea is to translate certain graphic flow diagrams into a proper
scripting language (a Python module), and execute that Python module then.
<br/>
*Functionaliy of the graphic modeler*
The functionalities of the sequencer are:
- Create a block: Make a double-click on the pane.
<img align="center" src="img3.jpg" width="400" description/>
- Resize block: Grep the border or the edge of a block
and pull it.
- Move block: Hold the left button and pull the block
- Mark block: Click into the block, it turns to yellow.
<img align="center" src="img4.jpg" width="400" description/>
- Unmark a block: Click somewhere outside the block.
- Delete a block: Mark the block, then press Delete.
- Generate an arrow between two blocks: Mark the first block,
then double-click into the second block. An arrow will be created.
<img align="center" src="img5.jpg" width="600" description/>
- Mark an arrow: Mark the beginning block, after that the end block.
The arrow between both ends will be marked.
<img align="center" src="img6.jpg" width="600" description/>
When you move around blocks in a model, then after the move operation all
arrows will get rearranged automatically.
Text can be added to the blocks. The text snippets will be interpreted
as a part of code during changing it to a Python module.
So the text snippets shall respect the syntax of python coding.
Hence, we have a subsequent process defined by blocks and code snipets
in the blocks. See the example here:
<img align="center" src="img7.jpg" width="600" description/>
<br/>
*Process fork*
A process in a model can *fork*, that means, two different paths can be
split off from the main path. This is the situation if a starting block
is connected to two other blocks. In this case the starting block turns
to a rhombe with a cross inside (see ... [img8] ...). This starting block
then should not have any txt inside, it marks only the forking of the
process.
<img align="center" src="img8.jpg" width="600" description/>
Remark: A fork block can only be inside of a process, not at the beginning.
In other words: A fork block always have a arrow coming in.
<br/>
*Process wait*
The opposite to a fork block is a block which waits for coming all running
subprocesses together. This waiting block has two incoming arrows and will
shape automatically to a rhombe with a circle inside.
See the image below for a complete example of forking and re-unite.
<img align="center" src="img9.jpg" width="800" description/>
<br/>
2.3. Reporting Module
-----------------------
The reporting module is in the planning phase. It evaluates data stored
in the central database which is populated by running the test sequences
with the runtime portion of the sequencer in the middleware (see below).
Elements of the reporting module are:
- Showing process values for the finished measuring processes.
- Showing grouped values of groups of measuring processes by
trend curves and curve bunches.
To show this elements on a GUI, there is prepared a certain series
of SQL statements which shows the respective data.
2.4. Simulation / Mocks
-------------------------
For the testing of the software, and replacing hardware elements by no-cost,
easy-to-use software elements, there is a concept for mocking:
- Simulations of sensor values: There is a randomly generating
measuring facility in the software (measure_simulation.py)
This is an easy-to-use module which sends out to a certain database table:
a) a time stamp
b) a measuring value, randomly generated, respecting some configuration
settings.
- Simulations of controls: There is a module regler.py which simulates
control over OPC-UA data access variables in a tree. This module contains
the methods:
start. Starts the Regler with a certain waiting time on a certain variable set.
regler. The algorithm how the variable set moves to the next step.
stop. Stop the Regler.
Instances of inherited regler-classes can be nested, so that complex
controls can be implemented. Some of such inherited classes are already
implemented (Interval, Rampe, Motor etc.).
The Regler classes take advantage of the Python/Qt mechanism to re-call
a method in the Qt runtime environment by sending an event to the
run-function in certain time intervals.
<p style="page-break-before: always;"></p></br>
<p class="break"/><!-- div class="header">...</div-->
3. Middleware
===============
3.1. Runtime Sequencer
------------------------
The runtime environment for the sequencer is a translation of the
graphic model to a certain Python class.
To translate the model to code is straightforward: Blocks become
functions in the class. Each function writes to a variable JUMP
at the end, so that the runtime environment knows which function
has to be executed next. The blocks itself contain the code snippets
from the graphics model.
After executing a block resp. a function the runtime environment
dumps the instance of the runtime python class into a database
in form of a serialized JSON data structure. The top level
of that bdata structure is a dictionary, whose keys arre assigned
to colums with the same name in the database table. If there is
a column missing, it will be created on the fly by an alter table
SQL statement. Additionally it can be appended a sleep time,
how long the process will have to be frozen in the database.
The runtime environment always checks whether dumped processes in
the database have to be re-invoked by reading the row and recreate
the respective python runtime process object.
That means, that the running process is accessible after being
stored into the database. It is possible to look at the row
where the process is stored. And for the aim for reporting the
finished process runs will be able to show in a reporting section.
<br/>
*Forking*
Forking is easily done in the Runtime Sequencer: It is only necessary
to copy a row in the database and let both rows proceed to run by
the runtime engine which greps both rows to the advised re-awake time.
Merging the split-off variable name spaces from both sub-processes
at a WAIT-Block is not trivial. Certain methods are
already discussed in the project.
3.2. Translator from Graphics Sequencer to Python Modules
-----------------------------------------------------------
The translator form graphics sequencer to the python runtime process module
works like that:
- Identify the blocks which are NOT forks NEITHER waits.
- Name functions accorrding to the blocks
- in the functions, copy all globals to locals.
- Read the arrow connections from the graphics and apply
certain JUMP-settings to the respective blocks / functions.
There was an attempt to apply this mechanism (which is bound to the
language Python) also in the MATROL environment (see below),
but this was not possible, because the graphic model and the
runtime sequence are too much connected together, and we have
strong dependency to Python.
3.3. OPC-UA Client
-------------------
The OPC-UA client in the middleware is able to read and write
variables in the OPC-UA tree in the backend. This is done
with the FreeOPCUA Pure Python Stack.
The implementation is straightforward, and has been tested
with an OPC-UA test server in Cpp.
The first working OPC-UA values in the backend could be
connected then to the Middleware (a voltage control for
steering the test stand motor).
<img align="center" src="img10.jpg" width="600" description/>
<p style="page-break-before: always;"></p></br>
<p class="break"/><!-- div class="header">...</div-->
4. Backend Connection
=======================
4.1. OPC-UA Server in the backend
-----------------------------------
The OPC-UA Server tree structure is built from an XML-file during
the start of the software by certain library calls. All tree nodes
have to be defined in that XML model.
The setting of values is done in a certain Python/Qt-module.
The interdependency of values are not finished, it is on the schedule.
The definition of a proper data model is done by the backend team of the project.
For now, there is only one parameter to set: The voltage of a certain motor
steering.
4.2. OPCUA Client - Events with data
--------------------------------------
The event paradigma of OPC-UA shall be used to transport data from
the measuring process itself into the GUI:
- The measuring process encapsulates certain portions of the measuring data
and sends it via the OPC-UA Server.
- The middleware catches this events and throughputs it.
- The frontend catches the events and draws portionwise the measuring
curve in a certain block of the graphical modeler (planned, to be done).
4.3. Performance Tests OPC-UA
-------------------------------
*Server Python / Client Python*
To prepare performance tests between backend and middleware, there
are test scripts which senbd out artificial data from a Python Server
to a Python Client. The results can be measured by:
- Latency. Results are less than 3 ms on a Intel i5 System.
- Data throughput. More than 20 MB / second is possible.
Both values are sufficient to run the communication between
backed ad middleware
<br/>
*Server C++ / Client Python*
The same tests are be done by replacing the Python OPC-UA Server
by a C++ OPC-UA server. The results are mostly the same like
the Python values above.
So the proof of concept for use of OPC-UA is given.
<p style="page-break-before: always;"></p></br>
<p class="break"/><!-- div class="header">...</div-->
5. Drivers
============
5.1. CANBus Interface
-----------------------
5.2. Tests of CANBus Interface
--------------------------------
<p style="page-break-before: always;"></p></br>
<p class="break"/><!-- div class="header">...</div-->
6. Mocks
==========
6.1. Mocks for Controls - Concept
-----------------------------------
6.2. Test implementations
---------------------------
<p style="page-break-before: always;"></p></br>
<p class="break"/><!-- div class="header">...</div-->
7. Matrol
===========
7.1. Concepts of Matrol
-------------------------
7.2. Sequencer model of Matrol
--------------------------------
7.3. Implementation of Matrol-like Sequencer
----------------------------------------------
<br/>
<p style="page-break-before: always;"></p></br>
<img src="iftbar1.svg" width="100%"/>