| 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_html.html |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<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-->
<h1 id="test-stand-software---new-architecture">Test Stand Software - New Architecture</h1>
<p><br/></p>
<p><br/></p>
<h1 id="general-architecture">1. General architecture</h1>
<p>A new generation for the RnD teststands at Kistler company shall include:</p>
<ul>
<li><p>A modern 3-layer architecture (Backend, Middleware, Frontend)</p></li>
<li><p>Including all measuring and steering facilities in the existing software</p></li>
<li><p>Extended configuration facilities for the end-user for</p>
<ol style="list-style-type: lower-alpha">
<li><p>Measuring processes</p></li>
<li><p>Parameter value set consistency checks</p></li>
<li><p>Reporting section</p></li>
</ol></li>
<li><p>Modularity</p></li>
<li><p>Maintainable</p></li>
</ul>
<p>The general architecture is described in the graphics [img1]</p>
<p><img align="center" src="img1.jpg" width="800" description/></p>
<h2 id="gui">1.1. GUI</h2>
<p>The GUI of the TSS shall contain the following elements:</p>
<ul>
<li><p>User administration</p></li>
<li><p>Configuration of the test stand</p></li>
<li><p>Configuration of the test object</p></li>
<li><p>Configuration of the test process (sequencer)</p></li>
<li><p>Consistency check</p></li>
<li><p>Control of test runs</p></li>
<li><p>Reporting section</p></li>
</ul>
<p>Each of that sections correspond to a certain screen of the TSS GUI [img2]</p>
<p><br/></p>
<p>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.</p>
<p>The connection form the frontend to the Middleware is done directly by liabray calls.</p>
<p>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.</p>
<h2 id="middleware">1.2. Middleware</h2>
<p>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.</p>
<p>The functions and controls shown in the GUI are connected to functionality in the middleware.</p>
<p>The middleware contains:</p>
<ul>
<li><p>data storage for the user administration</p></li>
<li><p>data storage for the configuration of the test stand</p></li>
<li><p>data storage for the configuration of the test objects</p></li>
<li><p>data storage of the sequences constructed in the GUI</p></li>
<li><p>data storage of the runtime data of the sequences</p></li>
<li><p>a connection to the backend via OPC-UA data access / events</p></li>
</ul>
<p>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.</p>
<p>In Python there is a free complete OPC-UA stack which can connect to the backend via data access and events.</p>
<h2 id="opcua-kiconnect">1.3. OPCUA / KiConnect</h2>
<p>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.</p>
<p>There are two methods being used in the middleware:</p>
<ul>
<li><p>Data access. It is used to control the parameters for the test stand, the test objects and general configuration data of the test stand.</p></li>
<li><p>Events. The events are used to send measuring data just in time to the middleware to show data directly and online.</p></li>
</ul>
<p>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).</p>
<p>The techniques to connect with data access / events from Python client (middleware) to CPP (backend) are realized in code and tested.</p>
<h2 id="backend">1.4. Backend</h2>
<p>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.</p>
<p>During the work, it became apparent, that this plan is not able to get into realization.</p>
<p>The reasons for that have been:</p>
<ul>
<li><p>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.</p></li>
<li><p>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.</p></li>
<li><p>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.</p></li>
</ul>
<p>For this reason, in the project the decision was made to start from the scratch in the backend.</p>
<p>It was planned to provide OPC-UA interfaces to all of the hardware components step by step.</p>
<p>Until the end of the project it was realized:</p>
<ul>
<li><p>A voltage control of test stand motor.</p></li>
<li><p>A CAN Bus test interface.</p></li>
</ul>
<p style="page-break-before: always;">
</p>
</br>
<p class="break"/>
<!-- div class="header">...</div-->
<h1 id="graphical-user-interface">2. Graphical User Interface</h1>
<p>It follows the description of the elements of the graphical user interface</p>
<p><br/></p>
<h2 id="user-administration">2.1. User administration</h2>
<p>The user administration distinguishes two kinds of users:</p>
<ul>
<li><p>Administrator</p></li>
<li><p>Normal user</p></li>
</ul>
<p>An administrator is allowed to access to all areas of the software, even creating new users (administrator and normal user), and granting access rights.</p>
<p>A normal user has limited access to the areas of the software. He shall not be allowed to create new users and grant access.</p>
<p>A detailed list of the allowed areas for administrator and normal user is given in the table [tab1]</p>
<p>... [tab1] ...</p>
<p>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.</p>
<p>The table with the access rights is hard-coded in the file core/config.py.</p>
<p><br/></p>
<h2 id="xml-configurator">2.2. XML Configurator</h2>
<p>The configuration of the teststand consists of three elements:</p>
<ul>
<li><p>the parameters of the test stand</p></li>
<li><p>the parameters of the test object</p></li>
<li><p>general parameters of the test procedures</p></li>
</ul>
<p>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).</p>
<p>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.</p>
<p>The XML-file is read at several stages in the running program:</p>
<ul>
<li><p>at program start (the test stand configuration will be read in)</p></li>
<li><p>when the test object is to be defined</p></li>
<li><p>when general test parameters are to be defined.</p></li>
</ul>
<p>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.</p>
<p><br/></p>
<h2 id="graphical-sequencer">2.2. Graphical Sequencer</h2>
<p>A main part of the GUI is a <em>graphical sequencer</em>.</p>
<p>This is a graphical configuration facility to define test procedures.</p>
<p>The idea is to translate certain graphic flow diagrams into a proper scripting language (a Python module), and execute that Python module then.</p>
<p><br/></p>
<p><em>Functionaliy of the graphic modeler</em></p>
<p>The functionalities of the sequencer are:</p>
<ul>
<li><p>Create a block: Make a double-click on the pane.</p>
<p><img align="center" src="img3.jpg" width="400" description/></p></li>
<li><p>Resize block: Grep the border or the edge of a block and pull it.</p></li>
<li><p>Move block: Hold the left button and pull the block</p></li>
<li><p>Mark block: Click into the block, it turns to yellow.</p>
<p><img align="center" src="img4.jpg" width="400" description/></p></li>
<li><p>Unmark a block: Click somewhere outside the block.</p></li>
<li><p>Delete a block: Mark the block, then press Delete.</p></li>
<li><p>Generate an arrow between two blocks: Mark the first block, then double-click into the second block. An arrow will be created.</p>
<p><img align="center" src="img5.jpg" width="600" description/></p></li>
<li><p>Mark an arrow: Mark the beginning block, after that the end block. The arrow between both ends will be marked.</p>
<p><img align="center" src="img6.jpg" width="600" description/></p></li>
</ul>
<p>When you move around blocks in a model, then after the move operation all arrows will get rearranged automatically.</p>
<p>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.</p>
<p>So the text snippets shall respect the syntax of python coding.</p>
<p>Hence, we have a subsequent process defined by blocks and code snipets in the blocks. See the example here:</p>
<p><img align="center" src="img7.jpg" width="600" description/></p>
<p><br/></p>
<p><em>Process fork</em></p>
<p>A process in a model can <em>fork</em>, 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.</p>
<p><img align="center" src="img8.jpg" width="600" description/></p>
<p>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.</p>
<p><br/></p>
<p><em>Process wait</em></p>
<p>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.</p>
<p>See the image below for a complete example of forking and re-unite.</p>
<p><img align="center" src="img9.jpg" width="800" description/></p>
<p><br/></p>
<h2 id="reporting-module">2.3. Reporting Module</h2>
<p>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).</p>
<p>Elements of the reporting module are:</p>
<ul>
<li><p>Showing process values for the finished measuring processes.</p></li>
<li><p>Showing grouped values of groups of measuring processes by trend curves and curve bunches.</p></li>
</ul>
<p>To show this elements on a GUI, there is prepared a certain series of SQL statements which shows the respective data.</p>
<h2 id="simulation-mocks">2.4. Simulation / Mocks</h2>
<p>For the testing of the software, and replacing hardware elements by no-cost, easy-to-use software elements, there is a concept for mocking:</p>
<ul>
<li><p>Simulations of sensor values: There is a randomly generating measuring facility in the software (measure_simulation.py)</p>
<p>This is an easy-to-use module which sends out to a certain database table:</p>
<ol style="list-style-type: lower-alpha">
<li><p>a time stamp</p></li>
<li><p>a measuring value, randomly generated, respecting some configuration settings.</p></li>
</ol></li>
<li><p>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:</p>
<p>start. Starts the Regler with a certain waiting time on a certain variable set.</p>
<p>regler. The algorithm how the variable set moves to the next step.</p>
<p>stop. Stop the Regler.</p>
<p>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.).</p>
<p>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></li>
</ul>
<p style="page-break-before: always;">
</p>
</br>
<p class="break"/>
<!-- div class="header">...</div-->
<h1 id="middleware-1">3. Middleware</h1>
<h2 id="runtime-sequencer">3.1. Runtime Sequencer</h2>
<p>The runtime environment for the sequencer is a translation of the graphic model to a certain Python class.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p><br/></p>
<p><em>Forking</em></p>
<p>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.</p>
<p>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.</p>
<h2 id="translator-from-graphics-sequencer-to-python-modules">3.2. Translator from Graphics Sequencer to Python Modules</h2>
<p>The translator form graphics sequencer to the python runtime process module works like that:</p>
<ul>
<li><p>Identify the blocks which are NOT forks NEITHER waits.</p></li>
<li><p>Name functions accorrding to the blocks</p></li>
<li><p>in the functions, copy all globals to locals.</p></li>
<li><p>Read the arrow connections from the graphics and apply certain JUMP-settings to the respective blocks / functions.</p></li>
</ul>
<p>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.</p>
<h2 id="opc-ua-client">3.3. OPC-UA Client</h2>
<p>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.</p>
<p>The implementation is straightforward, and has been tested with an OPC-UA test server in Cpp.</p>
<p>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).</p>
<p><img align="center" src="img10.jpg" width="600" description/></p>
<p style="page-break-before: always;">
</p>
</br>
<p class="break"/>
<!-- div class="header">...</div-->
<h1 id="backend-connection">4. Backend Connection</h1>
<h2 id="opc-ua-server-in-the-backend">4.1. OPC-UA Server in the backend</h2>
<p>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.</p>
<p>The setting of values is done in a certain Python/Qt-module. The interdependency of values are not finished, it is on the schedule.</p>
<p>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.</p>
<h2 id="opcua-client---events-with-data">4.2. OPCUA Client - Events with data</h2>
<p>The event paradigma of OPC-UA shall be used to transport data from the measuring process itself into the GUI:</p>
<ul>
<li><p>The measuring process encapsulates certain portions of the measuring data and sends it via the OPC-UA Server.</p></li>
<li><p>The middleware catches this events and throughputs it.</p></li>
<li><p>The frontend catches the events and draws portionwise the measuring curve in a certain block of the graphical modeler (planned, to be done).</p></li>
</ul>
<h2 id="performance-tests-opc-ua">4.3. Performance Tests OPC-UA</h2>
<p><em>Server Python / Client Python</em></p>
<p>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:</p>
<ul>
<li><p>Latency. Results are less than 3 ms on a Intel i5 System.</p></li>
<li><p>Data throughput. More than 20 MB / second is possible.</p></li>
</ul>
<p>Both values are sufficient to run the communication between backed ad middleware</p>
<p><br/></p>
<p><em>Server C++ / Client Python</em></p>
<p>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.</p>
<p>So the proof of concept for use of OPC-UA is given.</p>
<p style="page-break-before: always;">
</p>
</br>
<p class="break"/>
<!-- div class="header">...</div-->
<h1 id="drivers">5. Drivers</h1>
<h2 id="canbus-interface">5.1. CANBus Interface</h2>
<h2 id="tests-of-canbus-interface">5.2. Tests of CANBus Interface</h2>
<p style="page-break-before: always;">
</p>
</br>
<p class="break"/>
<!-- div class="header">...</div-->
<h1 id="mocks">6. Mocks</h1>
<h2 id="mocks-for-controls---concept">6.1. Mocks for Controls - Concept</h2>
<h2 id="test-implementations">6.2. Test implementations</h2>
<p style="page-break-before: always;">
</p>
</br>
<p class="break"/>
<!-- div class="header">...</div-->
<h1 id="matrol">7. Matrol</h1>
<h2 id="concepts-of-matrol">7.1. Concepts of Matrol</h2>
<h2 id="sequencer-model-of-matrol">7.2. Sequencer model of Matrol</h2>
<h2 id="implementation-of-matrol-like-sequencer">7.3. Implementation of Matrol-like Sequencer</h2>
<p><br/></p>
<p style="page-break-before: always;">
</p>
<p></br> <svg width="100%" id="id2" viewBox="0 0 190 14"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink">
<style type="text/css">
text.pagenr { font-family: Times New Roman; font-size: 6px; fill: #00acdf; }
</style>
<rect fill="#00acdf" height="5" width="172" x="0" y="9"/>
<image x="177" y="0" width="13" height="13" xlink:href="iftlogo1.jpg"/>
<text class="pagenr" x="2" y="6"><!--0/0--></text>
</svg>
</p>
</body>
</html>