Build-traffic light: the story of another introduction
Discussing the implementation of auto-testing in our company, the idea of visualizing the results using a traffic light was proposed. This tool is simple and clear to everyone, and also produces a small wow effect. Under the cut there will be a history of the introduction of a traffic light into our autotest system.
On the Internet a huge number of proposals for the purchase of a traffic light. We did not bother and collect our own, but immediately bought ready.
')
Traffic light is expensive. This model cost us almost 13,000 p. The big plus of such a traffic light is its compactness. The thickness of the traffic light, including peaks, is 275 mm. Without peaks 138 mm. Length 840 mm. The set includes brackets with which we hung it on a ... cabinet.
To control the traffic light, we decided to use the Quartech-Jackpot-USB discrete I / O card developed by our friends.
The control board is located in the traffic light body and controls three COSMO solid-state relays, providing with a large margin not only galvanic isolation, but also the required load capacity (if desired, more than one dozen such traffic lights can be controlled through them).
An extensible control protocol was developed and implemented, which allows using this board to control not only the traffic light, but also many other peripheral devices (power supply of surveillance cameras, lighting control systems, various buttons and sensors on demonstration layouts).
The system of automatic testing is written in the python3 language. At intervals of one minute, the presence of a new revision in the repository is checked. If such is present, it is pumped out, and tests are “pitted” against it. Tests are separate scripts on all the same python3, between which there are dependencies. Thanks to the dependencies, the tests are arranged in a certain sequence: first, a test is run that builds the project; behind him are “quick” tests; the last is all the rest. The results of the tests are placed in a database (sqlite).
A separate script implements a web server that visualizes the results of test execution.
The same web-server was taught to form a summary of the totality of tests. This feature is used to control the traffic light.
The configuration file contains the server address and a list of tests that will be monitored by the traffic light.
The logic of the traffic light in the test system is very simple:
A traffic light was placed before leaving the office. This gives a rather tangible psychological effect: a green traffic light is on - the path is clear (you can safely go home), red - you need to correct the error.
Search and purchase of traffic lights
On the Internet a huge number of proposals for the purchase of a traffic light. We did not bother and collect our own, but immediately bought ready.
')
Technical characteristics of the GOST R 52282-2004 LED traffic light:
• Minimum power consumption of a traffic light: not more than 6W (red and yellow section) and 8W (green section) per section;
• Operating supply voltage: 220V AC, in accordance with GOST 13109. According to tests, the dielectric strength of the insulation can withstand a voltage of at least 1500V at a frequency of 50 Hz without breakdowns for 1 min;
• Warranty from the manufacturer for 3 years. The service life of traffic lights at least 12 years. Durable energy-saving LED emitters (LEDs) are used. The average lifetime of LEDs is 100,000 hours;
• Operating temperature range of LED traffic lights: from - 60 to +60 ;
• Lighting parameters of traffic lights, axial luminous intensity of emitters of road traffic lights in accordance with GOST R 52282-2004;
• Small weight of the traffic light no more than 8 kg;
• Operating supply voltage: 220V AC, in accordance with GOST 13109. According to tests, the dielectric strength of the insulation can withstand a voltage of at least 1500V at a frequency of 50 Hz without breakdowns for 1 min;
• Warranty from the manufacturer for 3 years. The service life of traffic lights at least 12 years. Durable energy-saving LED emitters (LEDs) are used. The average lifetime of LEDs is 100,000 hours;
• Operating temperature range of LED traffic lights: from - 60 to +60 ;
• Lighting parameters of traffic lights, axial luminous intensity of emitters of road traffic lights in accordance with GOST R 52282-2004;
• Small weight of the traffic light no more than 8 kg;
Traffic light is expensive. This model cost us almost 13,000 p. The big plus of such a traffic light is its compactness. The thickness of the traffic light, including peaks, is 275 mm. Without peaks 138 mm. Length 840 mm. The set includes brackets with which we hung it on a ... cabinet.
Electronics
To control the traffic light, we decided to use the Quartech-Jackpot-USB discrete I / O card developed by our friends.
The control board is located in the traffic light body and controls three COSMO solid-state relays, providing with a large margin not only galvanic isolation, but also the required load capacity (if desired, more than one dozen such traffic lights can be controlled through them).
An extensible control protocol was developed and implemented, which allows using this board to control not only the traffic light, but also many other peripheral devices (power supply of surveillance cameras, lighting control systems, various buttons and sensors on demonstration layouts).
Control Protocol Description
The entire exchange is made in the mode of request-response from the PC, or in the mode of streaming data in a special mode.
Full duplex USB sharing through a virtual COM port, open at 9600kb / s.
The exchange between any devices occurs in the mode of direct connection. All messages at the transport level have a standardized format:
The current status bit field has the following fields:
bit 0: 0 - normal operation, 1 - error
bit 1: 0 - request waiting mode, 1 - streaming data
Each team consists of a “Team Number” field and an optional “Team Data” field. Even numbers of commands - requests, odd - answers.
If the response to the command is not received within the guard interval, then the connected device is considered lost.
Manage output lines of the board.
In the virtual COM-port, you must send the command 0x0A with the data corresponding to the desired state of the output lines. If it is necessary to signal only to the zero line, then in the data byte of the commands it is necessary to transmit 0x01. Thus, the whole team will look like this:
0x7E 0x02 0x00 0x0A 0x01 0x8B
in response to this command, if it is possible, the board will respond with a 0x0C command with data corresponding to the state of the installed output lines:
0x7E 0x02 0x00 0x0C 0x01 0x8D
or, if it is impossible to execute, will report an error:
0x7E 0x00 0x01 0x7F
Physical level
Full duplex USB sharing through a virtual COM port, open at 9600kb / s.
Transport level
The exchange between any devices occurs in the mode of direct connection. All messages at the transport level have a standardized format:
| Field | Starting byte | Team size (number + data) | Current status | Team number | Command data | Check sum |
| The size | one | one | one | one | 0-254 | one |
| Value | 0x7E | 1 - 255 0 - error | A bit field that determines the current state of each type of device. | 1 - 255 0 - error | Determined by the team | The sum of all previous message fields, including the start byte |
The current status bit field has the following fields:
bit 0: 0 - normal operation, 1 - error
bit 1: 0 - request waiting mode, 1 - streaming data
Command level
Each team consists of a “Team Number” field and an optional “Team Data” field. Even numbers of commands - requests, odd - answers.
| Team number | Command description | Data |
| 0x01 | Device Type Request | not |
| 0x02 | Device Type Response | 1 byte: 0 - error 1 - measuring part 2 - interface part 3 - PC |
| 0x03 | Serial Number Request | not |
| 0x04 | Serial Number Answer | 2 bytes |
| 0x05 | Request software version | not |
| 0x06 | Answer software version | 2 bytes |
| 0x07 | Request Iron Version | not |
| 0x08 | Iron version response | 2 bytes |
| 0x0A | Set port status | 1 byte |
| 0x0B | Request port status | not |
| 0x0C | Port Status Response | 1 byte |
| 0x0D | Turn on beeper, ms | 1-2 bytes |
| 0x0E | Jumper Status Request | not |
| 0x0F | Jumper Status Response | 1 byte |
| 0x10 | Request for input status (optocoupler) | not |
| 0x11 | Input Status Response | 1 byte |
| 0x12 | Query the number of input fronts | 1 byte (login number) |
| 0x13 | Answer the number of fronts of inputs | 5 bytes: 1st byte - entry number 2-3 bytes - the number of leading fronts 4-5 bytes - the number of rear edges |
| 0x14 | Batch request for the status of the inputs and the number of edges | not |
| 0x15 | Response to batch request for the status of inputs and counters of the number of edges | 33 bytes: 1st byte - input status 2-17 bytes - the number of leading edges of 2 bytes per input starting from zero 18-33 bytes - the number of rear edges of 2 bytes per input starting from zero |
| 0x16 | Resetting front counters | No (a 0x15 command with zero counter values is issued in response) |
| 0x20 | Setting the auto flashing bits of the outputs | 1 byte |
| 0x21 | Request set bits flashing outputs | not |
| 0x22 | The response of the set bits flashing outputs | 1 byte |
| 0x23 | Setting the blink time of output | 3 bytes: 1st byte - exit number 2-3 bytes - period in ms The default period is 500ms. If bytes 2-3 are 0, then the default period is set. |
| 0x24 | Output flashing period response | 3 bytes (similar to the 0x23 command) |
If the response to the command is not received within the guard interval, then the connected device is considered lost.
Example:
Manage output lines of the board.
In the virtual COM-port, you must send the command 0x0A with the data corresponding to the desired state of the output lines. If it is necessary to signal only to the zero line, then in the data byte of the commands it is necessary to transmit 0x01. Thus, the whole team will look like this:
0x7E 0x02 0x00 0x0A 0x01 0x8B
in response to this command, if it is possible, the board will respond with a 0x0C command with data corresponding to the state of the installed output lines:
0x7E 0x02 0x00 0x0C 0x01 0x8D
or, if it is impossible to execute, will report an error:
0x7E 0x00 0x01 0x7F
Testing system
The system of automatic testing is written in the python3 language. At intervals of one minute, the presence of a new revision in the repository is checked. If such is present, it is pumped out, and tests are “pitted” against it. Tests are separate scripts on all the same python3, between which there are dependencies. Thanks to the dependencies, the tests are arranged in a certain sequence: first, a test is run that builds the project; behind him are “quick” tests; the last is all the rest. The results of the tests are placed in a database (sqlite).
A separate script implements a web server that visualizes the results of test execution.
The same web-server was taught to form a summary of the totality of tests. This feature is used to control the traffic light.
Under the cut script code to control the traffic light:
#! /usr/bin/env python3 import sys, os, termios, threading, time, http.client if len(sys.argv)<=1: sys.exit("Usage: {0} CONFIG-FILE".format(sys.argv[0])) exec(open(sys.argv[1], "rt").read()) portfd=os.open(serialport, os.O_RDWR) # Configure serial port - make it "raw", set 9600 baud rate and 8N1 iflag,oflag,cflag,lflag,ispeed,ospeed,cc=tuple(termios.tcgetattr(portfd)) iflag&=~(termios.IGNBRK|termios.BRKINT|termios.PARMRK|termios.ISTRIP|termios.INLCR|termios.IGNCR|termios.ICRNL|termios.IXON) oflag&=~(termios.OPOST) lflag&=~(termios.ECHO|termios.ECHONL|termios.ICANON|termios.ISIG|termios.IEXTEN) cflag&=~(termios.CSIZE|termios.PARENB|termios.CSTOPB) cflag|=termios.CS8 ispeed=termios.B9600 ospeed=termios.B9600 termios.tcsetattr(portfd, termios.TCSANOW, [iflag, oflag, cflag, lflag, ispeed, ospeed, cc]) # Current state of traffic light: # 0 - fail (red light) # 1 - success (green light) # 2 - in progress (yellow light) # 3 - no data (blinking yellow) state=3 RED=0 YELLOW=1 GREEN=2 def trafficLightControl(light): cmd=[0x7E, 0x02, 0xFF, 0x0A] if light==RED: cmd.append(1) elif light==YELLOW: cmd.append(2) elif light==GREEN: cmd.append(4) else: cmd.append(0) cmd.append(sum(cmd)&0xFF) os.write(portfd, bytes(cmd)) def controlThreadProc(): while True: if state==0: trafficLightControl(RED) elif state==1: trafficLightControl(GREEN) elif state==2: trafficLightControl(YELLOW) else: trafficLightControl(YELLOW) time.sleep(1.5) trafficLightControl(None) time.sleep(1.5) controlThread=threading.Thread(target=controlThreadProc) controlThread.start() def pollThreadProc(): global state connection=None while True: try: if connection is None: connection=http.client.HTTPConnection(server) connection.request("GET", "/{0}/status?test={1}".format(project, ",".join(tests))) r=connection.getresponse().readall() state=int(r.decode("ascii")) except: state=3 connection=None time.sleep(5) pollThread=threading.Thread(target=pollThreadProc) pollThread.start() The configuration file contains the server address and a list of tests that will be monitored by the traffic light.
server="192.168.2.245" project="tvz-win-trunk" tests=['build', 'xmlcheck', 'qdebug', 'runss', 'runssc', 'tr_en', 'trcyr_en', 'warning1', 'warning10', 'warning100', 'xmldeps', 'issue16683a', 'issue17071', 'issue16796', 'runmain', 'issue17319', 'issue17318', 'issue17396a', 'smartstation_su', 'xmlrpcdoc_ss', 'src_encoding', 'issue17241', 'issue17228'] serialport="/dev/ttyUSB0" The logic of the traffic light in the test system is very simple:
- Red - test failed
- Yellow - test runs or recheck test
- Green - all tests completed successfully.
- Blinking amber - no connection to server
Results
A traffic light was placed before leaving the office. This gives a rather tangible psychological effect: a green traffic light is on - the path is clear (you can safely go home), red - you need to correct the error.
Source: https://habr.com/ru/post/216743/
All Articles