This document is not intended to explain how a SURVISION LPR unit can be installed and configured. For these technical questions, please refer to the Quick Start Guide of your product.

SURVISION would like to draw the reader’s attention to the fact that the below described principles are the result of the inventive activity of SURVISION and are therefore part of the company’s intellectual property. This document is provided on a strictly confidential basis and the reader is formally warned that the communication of this document to any of SURVISION’s competitors may potentially harm SURVISION which reserves the right to sue for compensation in this case.

Support

For any question about integration and software development, please contact integration_support@survision.fr.

For any technical question (installation, configuration), please contact support@survision.fr.

LPR units

LPR units covered by this document are the following:

Nanopak 1 & 2 : subsequently named as "legacy"
Micropak 1 & 2 : subsequently named as "legacy"
Visipak 1, 2 & 3 : subsequently named as "legacy"
Visipak 4 : subsequently named as "VPK4"
Nanopak 3 : subsequently named as "NPK3"
Micropak 3 : subsequently named as "MPK3"
Picopak 3 : subsequently named as "PPK3"
Nanopak 5 : subsequently named as "NPK5"
Micropak 5 : subsequently named as "MPK5"
Visipak 5 : subsequently named as "VPK5"
Citypak 5 : subsequently named as "CTK5"

Features

For each feature, the way to use it with supported interfaces and protocols will be described.

Note that some features are not supported by all LPR units.

License plates reading

Configuration

Some parameters can be set to change the way plates are read :

squarePlates	If true, the recognition engine is optimized for 2 lines plates detection. It allows the detection of 2 lines plates, but reduces the detection rate for standard plates. This should be activated only if you need to read specifically 2 lines plates.
squarePlatesOnly	If true, only 2 lines plates will be read.
waitForEnd	If true, the Decision is sent just before the END message : it waits for the vehicle to be not visible for sending the decision. This makes possible to have the most reliable information possible for each vehicle (direction/image of the entire vehicle, etc.). Be careful not to activate this option if the vehicle stops in the image or when the decision is expected while the vehicle is in the image.
reemitDecision	If true, decisions will be reemitted every 'reemitDecisionTimeout' ms while the plate is visible.
reemitDecisionTimeout	Time between 2 reemissions, in ms
context	Priority list for country detection. It contains a list of OVAL codes, separated by \| (the 2 countries have the same priority) or > (the first country will be chosen against the second). In addition, the last field can be set to '>OTHERS' for the sensor to be able to read foreign plates. In most cases, the context string should be set to the installation country code. For more details, please refer to the "Geographical coverage" documentation, which is downloadable on my.survision. The OVAL code definition can be found on http://www.unece.org/fileadmin/DAM/trans/conventn/Distsigns.pdf
direction	Direction filter : front : Read front plates only : only approaching plates will be sent rear : Read rear plates only : only going away plates will be sent both : All plates will be sent
duplicateFilter	If true, a plate won't be sent if it has already been read on the last 3 vehicles
trailerPlates	If true, the recognition engine is optimized for trailer plates detection. It increases the detection rate for trailer plates, but reduces the detection rate for standard plates. This should be activated only if you need to read specifically trailer plates.
counting	If true, the recognition engine is optimized for accurately detect all vehicles, including the ones without plates. It also decreases false positives and duplicates, but can reduce the decision rate. This should be activated only if you need to accurately count vehicles with this sensor. Note that it cannot be activated in Free Flow.
countingDirection	Main direction of vehicle movement. The direction will be detected as "standard" if it follows the selected direction. If it does not, it will be detected as reverse. : front : the main direction corresponds to an approaching vehicle rear : the main direction corresponds to a vehicle moving away
vehicleDetection	If true, the recognition engine will detect any movement which looks like a vehicle. Messages will be sent as for other vehicles, except that the 'plate' attribute in decision message will be empty. This should be activated only if you need to be sure to detect every vehicle, because it can greatly increase false detections. Note that vehicle detection can only be activated if Counting is not activated.
recognitionStorage	If true, the last free run messages (new, decision, speed, end) are kept in sensor internal memory. This can be useful if the sensor is installed on a unsure network. Note that if the sensor reboots (because of an electrical cut for example), all the stored messages are lost. Use synchronous message getLog to retrieve stored messages.
drawPlateOnImage	If true, some text is written on the JPEG sent with the decision. See drawPlateSyntax.
drawPlateSyntax	Syntax of the text written on the JPEG if drawPlateOnImage is true. The sensor will replace strings between * with the following values : y : year of the decision in UTC mo : month of the decision in UTC d : day of the decision in UTC h : hour of the decision in UTC mi : minute of the decision in UTC s : second of the decision in UTC ms : millisecond of the decision in UTC plate : the plate (? will be replaced with !) reliability : reliability context : context (\| will be replaced with !) It is possible to add line break with '\n'.
multiPlate	If true, multiple plates can be read at the same time.

Free run

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The "Free run" feature is useful when you want to install a LPR unit on a traffic lane, with no other system synchronized with it.

The LPR unit continuously works by itself, and is always looking for plates in the image. No request is needed to be sent to the LPR unit to get the plates. As a consequence, plates recognitions are sent to anyone connected to the LPR unit as soon as the LPR unit reads it.

Note that it is possible to force synchronization, if needed. See chapter Trigger synchronization.

CDK & SSWS interfaces

The CDK and SSWS will receive, for a given vehicle, the following asynchronous messages :

'New', the plate or vehicle becomes visible in the image.

msg/anpr/new

continue	If true, this session is the continuation of the previous one : this is the same vehicle. Note that the current session will have a decision message like a normal one.
x	X position of the plate in the image
y	Y position of the plate in the image
width	width of the plate
height	height of the plate
sinus	angle sinus of the plate to the horizontal. See subelement 'decision' for how to calculate precisely the position of the 4 corners of the plate rectangle

'Decision', the LPR unit has taken a decision and sends the informations found. Decisions can occur at any time between New and End events. The decision event contains most of the useful data about the vehicle (plate, country, etc). Multiple decisions may occur during the same session, with different reliability levels. The last one will have the best reliability.

msg/anpr/decision

plate	License plate
x	X position of the plate in the image
y	Y position of the plate in the image
xOrigin	If the image is cropped, X position in the original (non-cropped) image
yOrigin	If the image is cropped, Y position in the original (non-cropped) image
width	width of the plate
height	height of the plate
sinus	Angle sinus of the plate to the horizontal. Calculation of the 4 corners of the plate rectangle x, y, w and h are given in the rotated coordinate system. From these parameters, it is possible to calculate the exact coordinates of the plate rectangle. To understand well how it can be done, it is important to know that the angle is given for a pivot that is the center of the plate. First, we calculate the center of the plate : xc = x + w/2 yc = y + h/2 Then, we calculate the cosinus of the angle : cos = cos(asin(sinus)) We can then calculate the corners, from the center : top left xtl = xc - (w/2)fCos + (h/2)fSinus; ytl = yc - (w/2)fSinus - (h/2)fCos; top right xtr = xc + (w/2)fCos + (h/2)fSinus; ytr = yc + (w/2)fSinus - (h/2)fCos; bottom left xtl = xc - (w/2)fCos - (h/2)fSinus; ytl = yc - (w/2)fSinus + (h/2)fCos; bottom right xtr = xc + (w/2)fCos - (h/2)fSinus; ytr = yc + (w/2)fSinus + (h/2)fCos;
reliability	reliability (0 to 100, 100 is the best)
direction	vehicle direction : front : the vehicle is approaching rear : the vehicle is getting away unknown : the sensor was to able to detect direction
context	Context string (detected from the plate syntax). In most cases, this string will contain a unique OVAL code, corresponding to the detected country ('F' for France, for example). In case of a country with different states (US, Australia, Canada...), the ISO 3166-1 alpha-2 state code will be added after the country code ('USA/CA' for example) The OVAL code definition can be found on http://www.unece.org/fileadmin/DAM/trans/conventn/Distsigns.pdf For more details, see the Country context documentation on my.survision.
context_isoAlpha2	ISO 3166-1 alpha-2 country code (detected from the plate syntax). This attribute contains ONLY the country code. If you need the state code, check 'context' attribute. For more details, see the Country context documentation on my.survision.
context_isoAlpha3	ISO 3166-1 alpha-3 country code (detected from the plate syntax). This attribute contains ONLY the country code. If you need the state code, check 'context' attribute. For more details, see the Country context documentation on my.survision.
plateOccurences	Number of images on which the plate has been detected
plateFrom	if the sensor has a master/slave configuration, source of the plate : master : the plate has been read by the master sensor slave : the plate has been read by the slave sensor
plateBackground	Plate background colour : white black
contrast	Contrast of the plate. Can be useful to detect sensor malfunction
squarePlate	Set to true if the plate has 2 lines

msg/anpr/decision/database

Internal database data. This element is present only if the plate has been found in the internal database.

plate	Found plate (can be different from the plate read, if there is some tolerance)
distance	Levenshtein distance between the read plate and the found plate

msg/anpr/decision/reliabilityPerCharacter

Array containing each character reliability. Note that the sensor needs a learning phase during which these values won't be sent. In worst cases, it may need 200 vehicles.

msg/anpr/decision/reliabilityPerCharacter/char

One character

index	Index of the character inside the plate number, starting with 0
reliability	Reliability of the character (0 to 100, 100 is the best)

msg/anpr/decision/jpeg

JPEG file

msg/anpr/decision/contextJpeg

JPEG file from the associated slave context sensor

'Speed', the LPR unit has calculated the speed of the vehicle. Occurs just before the End event.

msg/anpr/speed

instantSpeed_km_h	speed in km/h
interdistance_ms	distance to the previous vehicle (in ms)
reliability_speed	reliability of the measured speed (0 to 100, 100 is the best)

'End', the plate or vehicle is not visible anymore.

msg/anpr/end

x	X position of the plate in the image
y	Y position of the plate in the image
width	width of the plate
height	height of the plate
sinus	angle sinus of the plate to the horizontal. See subelement 'decision' for how to calculate precisely the position of the 4 corners of the plate rectangle
plateOccurences	Number of images on which the plate has been detected
countingTrajectory	Detected vehicle trajectory, based on average trajectories. This attribute is present only if counting algorithm is activated. : standard : The vehicle used the standard trajectory. It should be considered as successfully passed. standardUnfinished : The vehicle used the standard trajectory, but did not finished it. It probably has turned around. It should be considered as NOT passed. reverse : The vehicle used the opposite trajectory compared to the standard one. It should be considered as successfully passed, but in the other way. reverseUnfinished : The vehicle used the opposite trajectory compared to the standard one, but did not finished it. It probably has turned around. It should be considered as NOT passed. falseDetection : The detection was not a vehicle and must not be taken into account.
trajectory	Detected vehicle trajectory. Contrary to "countingTrajectory", it does not take into account a "standard trajectory", thus, only tells if the vehicle is approaching or moving away. : unknown : The algorithm was unable to detect the vehicle trajectory. front : The vehicle was approaching. (it probably was the front plate which was visible) frontUnfinished : The vehicle was approaching but turned around. rear : The vehicle was moving away. (it probably was the rear plate which was visible) rearUnfinished : The vehicle was moving away but turned around.

HTTP Push

All Free Run messages can be sent through HTTP Push to specified servers. Messages format is in JSON, the same as for SSWS. For details about this format, please check the SSWS documentation.

Serial interface

When the LPR unit takes its decision, it will send a message on serial interface. This corresponds to the 'decision' message sent to CDK and SSWS.

There are 2 modes for message content (the mode is to be configured on the LPR unit) :

Only plates numbers are sent.

Example :

AA123AA!BB456BB!

Plates are exported with some metadata :

The internal LPR unit timestamp, corresponding to the number of milliseconds since the LPR unit booted
The plate
The country context
The width of the plate, in pixels
The LPR unit input IO state

Example :

254100:AA123AA:F:150:0!255200:BB456BB:F:147:0!

Wiegand

All plates read in 'decision' messages will be converted into a Wiegand code, and sent through the Wiegand interface.

OSDP

When an ODSP client polls, if a decision has been taken, the answer (Raw Card Data) will be filled with the plate. Note that one plate will be answered only once. At the next poll, if there is not a new decision, the answer will NOT contain the plate.

FTP interface

When the LPR unit takes its decision, it will send a JPEG image on FTP. This corresponds to the 'decision' message sent to CDK and SSWS.

The JPEG filename can contain the decision data (such as plate, country, etc). If the LPR unit has a context camera, it can also send the context image.

Trigger synchronization

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The "trigger synchronization" feature is useful when the LPR unit needs to exchange data to synchronize its information with other systems. For example, there can be another vehicle detection system, which gives other informations (class, height, weight of the vehicle...), or a simple detection loop.

You want then to ensure the different systems define the same vehicle.

One client application will trigger the LPR unit at the time when the synchronizing system knows there is a vehicle. Then, the LPR unit will send an unique decision - the trigger result - to all connected clients. The trigger system can be configured to answer as fast as possible (as soon as the plate is read and the trigger has been received), or with the better result possible (as soon as a plate with a minimum reliability is read and the trigger has been received - in the limits of the trigger window).

CDK & SSWS interfaces

Triggers are activated by synchronous messages 'triggerOn' and optional 'triggerOff':

triggerOn:

msg/triggerOn

Starts a trigger session

cameraId	ID of the camera on which the triggerOn has to be done. If not set, default to first camera (id=0)
forceTriggerId	If this attribute is set, the trigger ID for all trigger decisions linked to this trigger will be its value. Note that it's the client application responsability to ensure the uniqueless of this value. It is not recommended to use this attribute.
timeout	If this attribute is set, a triggerOff will be automatically generated by the sensor after the timeout (in ms). As a consequence, the triggerResult is ensured to have been sent before or at this timeout. If a triggerOff or another triggerOn is sent by the client application before this timeout, the trigger session is finished, like if there were no timeout.

triggerOff:

msg/triggerOff

Ends a trigger session

cameraId ID of the camera on which the triggerOff has to be done. If not set, default to first camera (id=0)

These synchronous messages will be answered by a 'triggerAnswer' message :

msg/triggerAnswer

Answer to a triggerOn or triggerOff message.

status	: ok : Everything went fine failed : There was an error. Check the errorText attribute for more details.
errorText	Error description, in case of error
triggerId	Trigger unique ID. All trigger decisions linked to this trigger will have this unique ID. The trigger ID is generated by the sensor, unless forceTriggerId attribute has been specified in triggerOn.

The 'triggerAnswer' does not contain the result of the trigger. This result will be sent asynchronously when the LPR unit has the best result possible, depending of the trigger configuration. Result is given as a 'triggerResult' message. The triggerResult is sent to all clients connected, even the ones which did not send the triggers messages.

msg/triggerResult

Trigger result

date	Timestamp of the used decision
triggerResultTimestamp	Timestamp of this message
triggerOnTimestamp	Timestamp of the triggerOn message
triggerOffTimestamp	Timestamp of the triggerOff message
triggerId	Id corresponding to the trigger that requested this result

msg/triggerResult/noPlate

msg/triggerResult/noPlate/jpeg

JPEG file

msg/triggerResult/decision

plate	License plate
x	X position of the plate in the image
y	Y position of the plate in the image
xOrigin	If the image is cropped, X position in the original (non-cropped) image
yOrigin	If the image is cropped, Y position in the original (non-cropped) image
width	width of the plate
height	height of the plate
sinus	angle sinus of the plate to the horizontal
reliability	reliability (0 to 100, 100 is the best)
direction	vehicle direction : front : the vehicle is approaching rear : the vehicle is getting away
context	Context string (detected from the plate syntax). In most cases, this string will contain a unique OVAL code, corresponding to the detected country ('F' for France, for example). In some rare cases, there may be an ambiguity between two countries, and the string will contain the 2 codes, separated with \|. (for example, CH\|L). The OVAL code definition can be found on http://www.unece.org/fileadmin/DAM/trans/conventn/Distsigns.pdf For more details, see the Country context documentation on my.survision.
plateOccurences	Number of images on which the plate has been detected
plateFrom	if the sensor has a master/slave configuration, source of the plate : master : the plate has been read by the master sensor slave : the plate has been read by the slave sensor
plateBackground	Plate background colour : white black
contrast	Contrast of the plate. Can be useful to detect sensor malfunction
squarePlate	Set to true if the plate has 2 lines

msg/triggerResult/decision/jpeg

JPEG file

msg/triggerResult/decision/contextJpeg

JPEG file from the associated slave context sensor

IO

A trigger session can be started by a IO input. It will end at the timeout defined in configuration for triggers on IO on.

Configuration

Configuration for trigger is in config/cameras/camera/anpr/trigger or config/cameras/camera/dgpr/trigger :

msg/config/cameras/camera/anpr/trigger

Trigger synchronization options. These parameters are useful only if you use the trigger synchronization mode.

A trigger can be sent to the sensor with software integration (CDK, SSWS), or with a IO in event.

reliabilityThreshold	If the sensor reads a plate with a reliability higher than this threshold, the result is immediatly sent as a triggerResult without waiting for the triggerOff. This permits to speed up trigger synchronization. Note that if this value is set to 0, the first decision will be sent ; if this value is set to 100, no triggerResult will be sent before the triggerOff.
endPlateTimeout_ms	Extension of the life of the plate, in ms. If a triggerOn is received after a plate is not visible anymore, but if it was visible less than 'endPlateTimeout_ms' ago, the plate will be used in the triggerResult. In normal installations, this value should be set to 500.
activateOnIOIn	If true, a triggerOn event will be generated by the sensor when IO in is detected. The triggerOn will be set with timeout 'triggerIOTimeout'
triggerIOTimeout	Timeout for the triggerOn event generated by IO in. (see triggerOn/timeout for more details)
triggerIOPulseMode	Pulse mode for IO in. The triggerOn event will be generated if pulse is modified to this value. : falling : Falling edge rising : Rising edge

Real time video streaming

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

SURVISION LPR units can stream their camera video stream to the client applications.

CDK interface

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The CDK will receive asynchronous 'video' messages :

msg/video

Video stream compressed image. Must be activated with setEnableStreams

cameraId	Unique ID of the camera sending this video frame
date	Timestamp
key	true if the video packet contains a I-Frame
codec	Codec type : jpeg : All images in video stream are a JPEG file mpeg : Video stream is encoded in MPEG-1 h264 : Video stream is encoded in H264. SPS and PPS packets are sent juste before each I-frame.

msg/video/data

data (binary)

RTSP interface

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

LPR units can stream a standard RTSP stream. URL is the camera ID. For example, if you want to get camera 0 stream, use :

rtsp://192.168.0.12/0

Configuration

Configuration for video stream is in config/cameras/camera/video:

msg/config/cameras/camera/stream

Video stream parameters. These parameters are only useful when you need to receive the video stream from the sensor.

enabled	If the video stream is enabled, it can be sent to the client if asked for
codec	Video codec : h264 : H264
fps	Video frame rate, in frames per second : 20 15 10 5 1
bitrate	Video stream bitrate in bits/s

Image buffering

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

It is possible to ask an image to the LPR unit.

By default, the LPR unit will answer with the last image. It is possible to ask for a specific timestamp in the past. Is may be useful if you need to get an image at the very precise time.

Notes:

If you ask for a specific timestamp, in order to work correctly, the LPR unit and the requesting application must have the same time. It is mandatory to have configured a NTP server on the LPR unit.
LPR units can keep only a few seconds in the buffer.

CDK & SSWS interfaces

The message 'getImage' must be sent as a synchronous request to the LPR unit:

msg/getImage

Request a video stream image from a camera with a specific timestamp.

type	If this attribute is not set, the both JPEG images are returned : jpeg contextJpeg
date	Requested timestamp. If no timestamp is set, the last image is sent.

The LPR unit will answer with a message 'image' (or 'answer' in case of error) :

msg/image

Video stream image

date	Image timestamp

msg/image/jpeg

JPEG

msg/image/contextJpeg

JPEG

Configuration

Configuration for video stream is in config/cameras/camera/stillPicture.

Note that these parameters are also used for images sent with decision messages.

msg/config/cameras/camera/stillPicture

There parameters define the size and quality of images in recognition messages and in the internal late stack. Images are compressed in JPEG. In recognitions, it is possible to crop the image around the read plate.

quality	Image quality : 0 to 100, 100 is the best
enabled	If still picture is disabled, no jpeg will be sent
plateCropped	Plate image cropped : full : Full image will be sent none : No image will be sent cif : Crop an image arround the plate in 352x288 smallest : Crop the smallest image arround the plate

Recognitions storage

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

SURVISION LPR units can keep in their internal memory the last "Free run" events (New, Decision, Speed, End), which can be requested by a client application.

This can be useful if the LPR unit is installed on a unsure network.

It can be desactivated to avoid keeping useless personal data on the LPR unit.

Note that if the LPR unit reboots (because of an electrical cut for example), all the stored events are lost.

CDK & SSWS interfaces

The message 'getLog' must be sent as a synchronous request to the LPR unit:

msg/getLog

Requests the anpr message (new, decision, end or speed) with specific Id If Id is set to 0, the most recent element is returned. If there is no element in history, or the Id does not exist in history, an error is returned. The history is limited to 2100 messages (each vehicle uses 3 messages : new, decision, end). Note : this function should only be used to request the anpr history (in case of disconnection for example). New messages will be received asynchronously as described in the CDK documentation.

id	Id of the requested anpr message. If it equals 0, the sensor returns the most recent one.

The LPR unit will answer with a message 'anpr', or 'dgpr' (or 'answer' in case of error) : See Free run chapter for details.

In order to get the full history, you should first send a 'getLog' message with ID 0 : the LPR unit will answer with the most recent event. Then get its ID, and try get send a 'getLog' with the previous ID. For example :

getLog[id=0] -> anpr/end [id=14524]
getLog[id=14523] -> anpr/decision [id=14523]
getLog[id=14522] -> anpr/new [id=14522]
getLog[id=14521] -> anpr/end [id=14521]
...
getLog[id=12423] -> answer/error : there is no more messages in memory.

Note that in normal case, you should only request the missing events since the LPR unit disconnection : you should keep the ID of the last received event, in order to stop sending 'getLog' when you get this event.

Relay output

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

It is possible to request the LPR unit to activate the relay output.

CDK & SSWS interfaces

The message 'openBarrier' must be sent as a synchronous request to the LPR unit:

msg/openBarrier

Opens the connected barrier.

Note that the state of the output (opened, closed), and the duration of its activation is in the configuration of the LPR unit.

Stand-alone operating

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The LPR unit can work autonomously with an internal license plate database.

If one of the plates in the database is read by the LPR unit :

it will automatically activates the relay output.
The 'anpr' message will be expanded with the 'database' sub element (see Free run chapter for more details).

The internal database can be set with CDK or SSWS. A Survision software called WLP can also help to set this database.

Configuration

Configuration can only be set with CDK or SSWS.

msg/config/database

If the internal database is enabled, when the sensor reads a plate corresponding to the criterias defined, the decision message will contain a 'database' element. In addition, the sensor will send a pulse (see IO configuration). You can use Survision application WLP to load plates in the database.

enabled	true if enabled
openForAll	If the barrier opens for all, a pulse will be sent for every plate read, even if not in the database
matchTolerance	Tolerance for plate read, in characters (uses Levenshtein distance)

Database management

To get the full database from the LPR unit, use 'getDatabase' :

msg/getDatabase

Requests the list of plates in sensor's internal database.

The LPR unit will answer with a 'database' message :

msg/database

The list of plates in internal database.

msg/database/plate

value

It is possible to erase all the database with 'eraseDatabase' :

msg/eraseDatabase

Empties the internal database.

or edit (remove and add) with 'editDatabase' :

msg/editDatabase

Edits the internal database. You can remove plates, or add plates.

msg/editDatabase/delPlate

value

msg/editDatabase/addPlate

value

Motion and shock detection

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

Note that Motion and shock detection is an option that may not be present on some LPR units.

Once activated, it will generate errors status on the LPR unit, which can be retrieved with the information message.

Configuration

Configuration can only be set with CDK or SSWS.

msg/config/imu

IMU configuration. This is used to configure the IMU sensor, if present.

enabled	true if the IMU is activated.
sensitivity	Sensitivity of the IMU : low : normal : high :

Error reset

Once an error has popup, it must be reset, with specific messages (with CDK or SSWS).

msg/imu/setReference

A new reference for motion detection will be set, with the current position of the sensor. It will also reset hit detection. Status flags 'ERROR_IMU_MOTION' and 'ERROR_IMU_HIT' will be removed.

msg/imu/resetHitDetection

Resets the hit detection. Status flag 'ERROR_IMU_HIT' will be removed.

Information about the LPR unit

It is possible to get from the LPR unit read-only informations (such as versions, temperatures, etc...).

CDK & SSWS interfaces

The informations can be requested by a synchronous message called 'getInfos'.

It is also possible to ask the LPR unit to send informations as asynchronous messages. Use 'setEnableStreams' to activate sending informations asynchronously. When activated, the whole informations message is sent. Then, only partial informations will be sent, every time something changes in informations.

The informations are sent as a 'infos' messages :

msg/infos

Informations message. Sent as an answer for getInfos or sent asynchronously if enabled with the setEnableStreams message.

msg/infos/sensor

type	Sensor type
POE	True if the sensor supports POE
IMU	True if the sensor has an IMU (Inertial Measurement Unit)
firmwareVersion	Firmware version
carrierBoardVersion	Carrier board version
loaderVersion	Loaded version
osVersion	OS version
productVersion	Product version
buildDescription	Build description
serial	Serial number
macAddress	Sensor's MAC address
status	Sensor's status : a list of strings, separated by \|. The first string in the list is the global status of the sensor. It can take the following values: RUNNING : the sensor is running. If this status is not set, the sensor cannot be used correctly. NO_FACTORY : the sensor has not been configured in factory. The sensor must be sent back to maintenance. INITIALIZING : the sensor is in the initialization phase. This is a temporary status. Note that during this phase, there may be status errors, that will disappear when the initialization process is finished. INITIALIZING_SPEED : Only available for sensor with speed option. The system is still initializing its speed recognition engine. Some vehicle speed might not be given during initialization. In addition to this global status, there may be one or more detailed error status: ERROR_CARRIERBOARD : Carrier board communication interrupted. This may be resolved by sending back the sensor to maintenance. ERROR_CAMERA : Camera synchronization error. This may be resolved by sending back the sensor to maintenance. ERROR_LED : LED board error. This may be resolved by sending back the sensor to maintenance. ERROR_TOOCOLD : Internal temperature is too low. ERROR_POWER : Power error. This may be resolved by checking power supply. ERROR_NTP : NTP error. This may be resolved by configuring a correct NTP server. If NTP is misconfigured, all timestamps will be invalid. ERROR_CONFIG_SPEED : Only available for sensor with speed option. Speed configuration Error. This may be resolved by modifying the installation. Too many different vehicle trajectories found. ERROR_CST : the sensor is unable to send CST messages to the configured CST server. ERROR_MOOBYL : the sensor is unable to send messages to the configured Moobyl server. ERROR_MOOBYL_DEGRADED_MODE : service behind Moobyl server does not work properly. In this case, the sensor uses its internal database to automatically open barrier. ERROR_FOCUS : the read plates seem not focused. This may be due to an incorrect configuration or dirt on the camera. ERROR_AVAR : the AVAR secondary sensor is not reachable. ERROR_SBFREEFLOW : SBFreeFlow protocol error. Server may be unreachable ERROR_SBFREEFLOW_UNAUTHORIZED : SBFreeFlow protocol error : request unauthorized by server (bad password?) ERROR_AMANOONE : AmanoOne protocol error. Server may be unreachable ERROR_AMANOONE_UNAUTHORIZED : AmanoOne protocol error : request unauthorized by server (bad password?) ERROR_TIBA : Tiba protocol error. Server may be unreachable ERROR_TIBA_UNAUTHORIZED : Tiba protocol error : request unauthorized by server (bad password or token?) ERROR_MODEM : Modem is not working ERROR_IMU : IMU is not working ERROR_IMU_HIT : IMU has detected a hit. This status can be reset with the message imu/resetHitDetection. ERROR_IMU_MOTION : IMU has detected a change in camera orientation. This status will be reset when a new reference will be set with the message imu/setReference. ERROR_MODBUSLYON : Modbus/Lyon protocol error. Server may be unreachable
reboots	Total reboots count
unexpectedReboots	Unexpected reboots count
locked	true if the sensor is locked.
setConfigForbidden	true if configuration modification is forbidden.
lockingClientIP	IP address of the computer locking the sensor
tracesAvailable	true if debugging traces are available for download.

msg/infos/sensor/technicalCounters

Contains all counters used to detect technical problems.

msg/infos/temperature

temperature_C	Current equipment temperature (in °C)
temperatureCPU_C	Current CPU temperature (in °C)

msg/infos/cameras

msg/infos/cameras/camera

id	Unique ID for the camera
cameraModel	Model of the camera
size	Native resolution
filter	type of the glass in front of the cameras : unfiltered : Nothing is filtered. ir : Visible light is filtered, only IR is viewed by the cameras ircut : IR are filtered, only visible light is viewed by the cameras motorized : A motorized IRCut filter can be activated by software. If not, nothing is filtered.
hasFlip	true if the camera can be vertically flipped

msg/infos/cameras/camera/zoomValues

min	Minimum value for zoom
max	Maximum value for zoom

msg/infos/cameras/camera/focusValues

min	Minimum value for focus
max	Maximum value for focus

msg/infos/cameras/camera/shutterValues

msg/infos/cameras/camera/shutterValues/value

text

msg/infos/cameras/camera/gainValues

min	Minimum value for gain
max	Maximum value for gain

msg/infos/cameras/camera/expCompValues

min	Minimum value for exposure compensation
max	Maximum value for exposure compensation

msg/infos/cameras/camera/enabledAlgorithms

msg/infos/cameras/camera/enabledAlgorithms/anpr

If this element is present, the ANPR engine is installed on the sensor.

msg/infos/cameras/camera/enabledAlgorithms/speed

If this element is present, the speed detection engine is installed on the sensor.

msg/infos/cameras/camera/enabledAlgorithms/trigger

If this element is present, the sensor supports trigger feature.

msg/infos/cameras/camera/enabledAlgorithms/plateSignature

If this element is present, the plate fingerprint engine is installed on the sensor.

msg/infos/cameras/camera/enabledAlgorithms/dgpr

If this element is present, the DGPR engine is installed on the sensor.

msg/infos/cameras/camera/enabledAlgorithms/video

If this element is present, the Video engine is installed on the sensor.

msg/infos/cameras/camera/enabledAlgorithms/counting

If this element is present, the Counting engine is installed on the sensor.

msg/infos/cameras/camera/enabledAlgorithms/outOfFocusDetection

If this element is present, the out of focus detection engine is installed on the sensor.

msg/infos/network

msg/infos/network/interfaceWifi

macAddress	Sensor's Wifi interface MAC address
connected	true if the sensor is in client mode and is well connected to the access point

msg/infos/security

This element contains informations about security configuration on the sensor. These parameters may be changed with the setSecurity message.

lockPasswordNeeded	true if a password is set for locking sensor
lockPasswordHint	Hint for password
rsaCrypted	true if plates are crypted with a RSA public key
rsaHint	Hint for RSA encryption, to know which key is used.

msg/infos/security/certificate

Informations about the certificate installed on the sensor, for SSL connections

commonName	Certificate name
organizationName	Certificate organization name
validityFrom	Validity start date
validityTo	Validity end date

msg/infos/security/IEEE8021X

Informations about the IEEE802.1X authentification

authentication	Authentication method : none : 802.1X is disabled eap-tls : Transport Layer Security. Need client certificate and key
commonName	IEEE802.1X certificate name
organizationName	IEEE802.1X certificate organization name
validityFrom	IEEE802.1X certificate Validity start date
validityTo	IEEE802.1X certificate Validity end date

msg/infos/anpr

version	Version of the ANPR engine
possibleContexts	list of all supported contexts, separated by \|

msg/infos/anpr/ocrDefault

This element contains default OCR parameters values.

minPlateWidth	Min plate width in pixels
maxPlateWidth2	Max plate width in pixels
minPlateHeight	Min plate height in pixels
maxPlateHeight2	Max plate height in pixels
zoomPlateWidth	Optimal plate width for the algorithm
minReliability	Minimum reliability to send a decision
minCharWidthStatic	Minimum width for a character to take a static decision
minPlateWidthStatic8Char	Minimum width for a plate to take a static decision
minRecognitionStatic	Minimum number of occurencies to take a static decision
minRecognition	Minimum number of occurencies to take a decision
maxNoPlateBeforeDecision	Number of images without any plate after the last occurencie to send the decision

msg/infos/dgpr

version

Version of the DGPR engine

msg/infos/lightings

msg/infos/lightings/led

id	Unique ID of the LED internal board
ledModel	LED board model
color	Color mode : infrared white

msg/infos/lightings/led/currentValues

min	Minimum value for power
max	Maximum value for power

msg/infos/lightings/projector

id	Unique ID of the projector
ledModel	Projector model

msg/infos/lightings/projector/delayValues

min	Minimum value for delay
max	Maximum value for delay

msg/infos/services

msg/infos/services/cst

performanceValidationActivated	true if Performance validation is activated on the sensor.
performanceValidationStarted	true if Performance validation is started on the sensor. Plates are sent to CST server ONLY if performanceValidationStarted is true.

msg/infos/modem

type	Model type of the modem, if present
IMEI	IMEI number of the modem, if present
signal	Quality of signal. Values can be 0 to 30 : 0-9 : bad signal 10-14 OK 15-19 : good 20 and more : excellent 99 : unknown
network	Connected network name
status	Connection status
hasSim	true if a SIM card is detected
address	IP address

LPR unit configuration

Get with CDK or SSWS

Like read-only informations, it is possible to ask configuration with a synchronous message, called 'getConfig'.

It is also possible to ask the LPR unit to send configuration as asynchronous messages. Use 'setEnableStreams' to activate sending configuration asynchronously. When activated, the whole configuration message is sent. Then, only partial configuration will be sent, every time something changes in configuration.

The configuration is sent as a 'config' messages. As the definition of this message is pretty big, you will find it in different chapters of this documentation, for each interface or feature it configures.

Set with CDK of SSWS

Although The LPR unit can be configured through the CDK or SSWS, it is highly recommended to use the VSS software to configure the LPR units, to avoid misconfiguring.

Use synchronous message 'setConfig' to configure the LPR unit. It will be answered with a 'answer' message.

Security

Security configuration is a specific configuration message, because most of its parameters can not be get. Security configuration results can be seen in information message.

Use message 'setSecurity' to send security configuration :

msg/setSecurity

Request for modifying the security configuration

newLockPassword	Password for locking sensor. If set, user will need to pass this password in the 'lock' message in order to lock the sensor
currentLockPassword	To change the lock password (newLockPassword), the current lock password must be provided. If there is no current password, this attribute can be not sent
lockPasswordHint	Hint for password : this attribute will be sent in infos message, and can be used to retrieve a lost password
rsaHint	Hint for encrypted plates : this attribute will be sent in infos message, and in anpr/decision messages. It should contain an unique ID used to know what private key is to be used for decrypting the plateCrypted attribute.
rsaPublicKeyPassword	Password to decrypt RSA public key when sending 'rsaPublicKey'.
sslCertificatePassword	Password to decrypt SSL keys
sslCertificateReset	Regenerate Self-Signed certificate

msg/setSecurity/sslPFX

This element may contain the PFX certificate (PKCS12) as binary data. If this element exists, elements sslCertificate, sslPrivatePey and sslCertificateAuthority must not exist

msg/setSecurity/sslCertificate

This element may contain the SSL Certificate as binary data

msg/setSecurity/sslPrivateKey

This element may contain the SSL private Key as binary data

msg/setSecurity/sslCertificateAuthority

This element may contain the SSL Certificate authority as binary data

msg/setSecurity/rsaPublicKey

If a RSA public key is configured, anpr/decision messages will not contain the attribute 'plate', but an attribute 'plateCrypted', containing the plate crypted with this key.

The padding used is RSA_PKCS1_PADDING. It is also recommended to set a rsaHint, that will be sent in the anpr/decision message with the encrypted plate. This attribute will be useful to know the plublic key used for encryption, and thus, use the correction private key.

To decrypt the plate, the OpenSSL function RSA_private_decrypt can be used. See CDKToolBox/CDKSecurityRSA for an example.

If this field is sent empty, RSA encryption will be disabled.

msg/setSecurity/IEEE8021X

Request for modifying the 802.1X security configuration

certificatePassword	Password to decrypt SSL keys
identity	EAP Identity
authentication	Authentication method : none : 802.1X is disabled eap-tls : Transport Layer Security. Need client certificate and key

msg/setSecurity/IEEE8021X/PFX

This element may contain the PFX certificate (PKCS12) as binary data. If this element exists, elements certificate, privateKey and certificateAuthority must not exist

msg/setSecurity/IEEE8021X/certificate

This element may contain the SSL Certificate as binary data

msg/setSecurity/IEEE8021X/privateKey

This element may contain the SSL private Key as binary data

msg/setSecurity/IEEE8021X/certificateAuthority

This element may contain the SSL Certificate authority as binary data

Traces & debug informations

You can find some debug informations in the infos message : rebootCount, technicalCounters...

In addition, it is possible to subscribe, with the CDK or SSWS, to 'trace' messages, with 'setEnableStreams'.

It is also possible to ask for traces history :

msg/getTraces

Traces request

Answer will be a 'traces' message :

msg/traces

History of last traces. The traces are given as 2 binary elements.

msg/traces/currentExecution_old

Contains the oldest traces as binary

msg/traces/currentExecution_current

Contains the newest traces as binary

Technical counters can be reset with the message 'resetCounters' :

msg/resetCounters

Reset firmware counters

XSD

Each LPR unit contains a XSD file, on which all messages are validated before being accepted by the LPR unit.

This XSD contains also all the documentation about each element and attributes of exchanged messages.

It is possible to get the XSD, with the CDK of SSWS, with message 'getXSD':

msg/getXSD

Asks for server XSD file.

Answer will be a 'xsd' message:

msg/xsd

The XSD, as binary data of this element

Interfaces & protocols

It is possible to communicate with SURVISION LPR units through different ways. This chapter presents in details these interfaces.

Not all these interfaces can support all of LPR units features. Details of what can be done or not can be found for each feature in the corresping chapter.

Global data encoding

All of the interfaces use the same encoding for data. This chapter presents the encoding format for data.

Strings

Strings are formatted in UTF-8. When sending strings to LPR unit, they must be formatted in UTF-8. If the LPR unit receives data in another format, it may disconnect the client.

Numbers

Numbers are formatted as ASCII strings.

Dates

Dates are formatted as Unix epoch time : this is the number of milliseconds that have passed since 1970-01-01 00:00:00.000.

As a number, they are finally formatted as an ASCII string.

Plates syntax

All plates numbers are sent in UTF-8, in left-to-right order, without any space.

In some rare cases, the LPR unit can be unable to read a character. This character will then be replaced by a '?'.

For alphabets that are not read in left-to-right order, a specific Unicode sequence {0xE2,0x80,0xAD} is added at the beginning of the plate to force the left-to-right order.

For example, in Morocco, plates contain arabic characters. As arabic is normally read right-to-left, the string sent will contain the left-to-right unicode sequence at its beginning.

"‭3545د8" will be encoded as {0xE280AD}3545{0x062F}8

In some coutries, there can be symbols on the plate that are not characters. If these symbols are mandatory for the unicity of the plate (and only if they are mandatory), they will be represented in the string sent with a '-'.

For example, french plates have 2 dashes ('-'), separating numbers and letters (AA-123-AA). But, as these dashes are not useful for the unicity of the plate, they are not sent by the LPR unit. A french plate will be sent as AA123AA.

On the contrary, in Germany, a stamp can be printed on the plate. Depending on its position on the plate, the plate does not identify the same vehicle (AA-A123 and A-AA123). As a consequence, the position of this stamp on the plate is represented as a dash.

Country identification

SURVISION LPR units detect the country from the plate syntax. A country is identified by its OVAL code.

The OVAL code definition can be found on UNECE website.

In some rare cases, there may be an ambiguity between two countries, and the string will contain the 2 codes, separated with |. (for example, CH|L).

Note that a country must have been integrated for its plates to be read correctly. To check if a country is integrated, please refer to Geographical coverage documentation.

Images

All images sent by SURVISION LPR units are encoded in JPEG, and can be decoded with any standard JPEG decoder.

They can also be simply saved on disk, and opened by any image viewer software.

Reliability

The LPR unit calculates, for each decision, a reliability level, represented as an integer between 0 and 100 (100 is the best).

Note that if the plate contains a '?', the reliability is set to 0 (as we are sure the plate is false).

SURVISION protocols

There are two different proprietary protocols used by SURVISION LPR units :

NPP : the legacy protocol, used on old LPR units : Micropak 1 & 2, Nanopak 1 & 2, Visipak 1, 2 & 3. These LPR units are not sold anymore.
CLP : the current protocol, used on all other LPR units.

The CDK interface

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The CDK is the Survision proprietary API to communicate with SURVISION equipments. It automatically manages connection and disconnection/reconnection from equipments, and is ensured to be compatible with all future versions of the CLP and NPP protocols.

The CDK can equally connect to a NPP LPR unit or a CLP LPR unit : the 2 protocols are managed by the API. NPP messages are transformed into CDKMsg inside the CDK.

The CDK manages the exchanges of messages between the client application and the LPR unit.

A message can be sent synchrously by the client - it is a "request", and will be answered.

Messages can be sent asynchronously by the LPR unit to the clients.

For more informations about the CDK, check the CDK documentation.

Note that the CDK can use secured connection (over SSL/TLS) to the LPR units.

msg/config/network/clp

An application based on Survision CDK will connect to the sensor using one of the CLP ports. Connections can be achieved without encryption, or with TLS encryption. Each mode has a specific listening port. It is possible to desactivate unsecured listening port to enforce security.

port	Listening port for unsecured connections
enableUnsecuredConnections	If set to false, unsecured connections won't be accepted. 'port' won't be used.
portSsl	Listening port for secured connections

The SSWS interface

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

SSWS is the web interface to communicate with SURVISION equipments.

As for the CDK, clients can sent synchronous requests, using HTTP POST.

Asynchronous messages can be received through a WebSocket connection.

Note that SSWS can be used on HTTP and HTTPS.

For more informations about SSWS, check the SSWS documentation.

msg/config/network/ssws

Survision Sensors Web Services (SSWS) allow communication over HTTP(S) and Websocket (Secure) with the sensor, using standard REST interfaces.
Synchronous messages can be sent as JSON POST request at http(s)://IP/sync.
Asynchronous messages can be sent and received as JSON at ws(s)://IP/async.
An application using SSWS will connect using SSWS ports. Connections can be achieved over HTTP or HTTPS. Each mode has a specific listening port. It is possible to desactivate one or other, to enforce security.

enableHttp	Enable HTTP and Websocket service.
httpPort	Port number for the HTTP and Websocket service.
enableHttps	Enable HTTPS and Websocket Secure service.
httpsPort	Port number for the HTTPS and Websocket Secure service.

HTTP Push

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The LPR unit can be configured to automatically send decisions to an HTTP server. Messages format is in JSON, the same as for SSWS. For details about this format, please check the SSWS documentation.

Note that HTTP Push can be used on HTTP and HTTPS.

msg/config/network/httpPush

HttpPush sends asynchronous messages to a remote server using HTTP/HTTPS POST requests.
Messages are encoded using the same JSON conversion used by SSWS.
The sensor emitting the request also adds identification information as HTTP headers:

Survision-Mac-Address : the MAC address of the sensor
Survision-Serial-Number : its serial number
Survision-Sensor-Name (since 2.7.0.0) : its name (as defined in configuration)

The server is expected to answer with the status code 200 if the request has been successfully handled. If the request cannot be delivered within a defined time period, either due to network error or a server error, the message is discarded.
If the server or network can’t handle messages sent from the sensor fast enough, HttpPush will buffer a limited amount of pending message, after that older messages are dropped and an HTTP header is added indicating the amount of messages lost (Survision-Messages-Dropped).
Asynchronous messages are guaranteed to be delivered in order inside one HTTP session. 'ANPR' and 'DGPR' also include a session number.

msg/config/network/httpPush/servers

List of servers to which to send the messages.

msg/config/network/httpPush/servers/server

An HTTP/HTTPS server expecting POST request from sensors.

id	The server identifier, it must be a positive number in the range [0,1].
enable	A boolean value to enable or disable transmission to this server.
url	An URL indicating how to contact the server. Supported protocol include HTTP and HTTPS. The format should be as follows: http[s]://server.example.org[:port]/target
username	Username for basic Auth.
password	Password for basic Auth.
filter	A comma separated list of asynchronous message name that will not be send to the server. A top level name, as 'anpr' will prevent any anpr message to be sent. To filter at a sub-message level, sub element name should be separated with a slash, for example 'anpr/new'.
timeout	An integer defining how much time the connection to the server is kept open since the last message was sent. To avoid the time and computational cost of opening a connection to the server, HttpPush reuses the existing connection to pipeline new messages in the already open connection. A positive value for a time delay in milliseconds, 0 for an infinite delay, and -1 to close the connection after each message.
ignoreSSLErrors	If true, SSL errors on the server are ignored.

msg/config/network/httpPush/servers/server/certificate

A string containing (the public) certificate to perform identity validation of the server

Serial

Available on :	legacy (except NPK)	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

A client application can connect to the LPR unit on Serial (RS232 or RS485, depending on LPR unit).

Use the following parameters to connect to the LPR unit:

Speed : 9600 bauds
No parity
1 stop bit

Once connected, the client application will receive asynchronous messages from the LPR unit. Each message ends with the '!' character.

Serial export must have been activated on the LPR unit.
No synchronous message can be sent through this interface.
No image is sent on Serial interface.

Configuration for serial export is in config/cameras/camera/anpr/serial or config/cameras/camera/dgpr/serial :

msg/config/cameras/camera/anpr/serial

These parameters are only useful when you want to export plate data on the serial port.

export

Export mode :

off : No export
simple : Plates are exported, separated with !
advanced : Plates are exported with some metadata : TIMESTAMP:PLATE:DETECTED_CONTEXT:WIDTH:IO_STATE!
osdp : Plates are exported using OSDP protocol
wiegand : Plates are exported using WIEGAND protocol

msg/config/cameras/camera/anpr/serial/wiegand

protocol	Size of the Wiegand frame. Default is 26 bits : 37bits : Plate are exported using the 37 bits mode of the wiegand protocol 26bits : Plate are exported using the 26 bits mode of the wiegand protocol
bitDuration_us	Period of time (in milliseconds) during which the bit stays on the bus. Default to 50 : 50 100
inactiveStateVoltage_V	Voltage of D0 and D1 when the bus is in inactive state. Default to 5V : 5 0

msg/config/cameras/camera/anpr/serial/osdp

address

Wiegand

Available on :	legacy (except NPK)	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

Note that legacy units, VPK4, MPK3, NPK3 and PPK3 do not natively support the Wiegand protocol. An external electronic card (the SURVISION Wiegand card) is mandatory. The Wiegand card must be connected to the Serial LPR unit's output. It will then transform ANPR plate into Wiegand code. In this case, the LPR unit must be configured for standard Serial export in order for the Wiegand to work.

Since version 5 units, Wiegand is natively supported.

msg/config/cameras/camera/anpr/serial/wiegand

protocol	Size of the Wiegand frame. Default is 26 bits : 37bits : Plate are exported using the 37 bits mode of the wiegand protocol 26bits : Plate are exported using the 26 bits mode of the wiegand protocol
bitDuration_us	Period of time (in milliseconds) during which the bit stays on the bus. Default to 50 : 50 100
inactiveStateVoltage_V	Voltage of D0 and D1 when the bus is in inactive state. Default to 5V : 5 0

OSDP

Available on :	legacy (except NPK)	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The LPR unit works as a PD, and will answer to ACU requests.

msg/config/cameras/camera/anpr/serial/osdp

address

FTP

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The LPR unit can be configured to automatically send decisions to FTP servers. All Free Run results will be sent to the configured FTP servers.

Supported protocols are FTP, FTPS and SFTP. Up to 4 FTP servers can be configured.

If the server is not available when the LPR unit tries to send the image, the LPR unit will retry to send it after a given timeout. Up to 16 decisions can be kept in memory waiting to be sent. If the queue is full, all new decisions will be dropped.

For each decision, a JPEG file will be uploaded on the FTP servers. The JPEG filename can contain the decision data (such as plate, country, etc). If the LPR unit has a context camera, it can also send the context image.

Configuration for FTP export is in config/network/ftp :

msg/config/network/ftp

The sensor can push every decision to FTP servers. Up to 4 servers can be specified.
For every decision taken, the sensor will generate a JPEG image of the decision, and will send it to the configured FTP servers. A second JPEG can be generated, containing the context image.
During the file transfert, the filename is postfixed with ~. It is removed at the end of the transfert.
Filename syntax is fully configurable, and can contain directories. If the directory does not exist, it will be automatically created.

enabled

If true, the sensor will push decisions on specified FTP servers, as JPEG images.
Note that this attribute, and "enabled" attribute of subelements serverX must be set to true for FTP export to work.

msg/config/network/ftp/servers

msg/config/network/ftp/servers/server0

First server configuration

enabled	If true, the sensor will push decisions to this server.
address	FTP server address. Can be an IP address or an host name
port	FTP server port. If not specified, the default value is used (21 for FTP and FTPS, 22 for SFTP)
login	Login
password	Password
protocol	FTP server protocol. Default value is FTP : ftp : File Transfer Protocol ftps : File Transfer Protocol Secure : using explicit SSL secure mode to connect sftp : SSH File Transfer Protocol
retryCount	If a file cannot be pushed to the server, the sensor will retry until this counter is reached. Default value is 3.
retryDelay_ms	Time waited, in ms, between retries. Default value is 30000 ms.
fileName	Name of generated files. The sensor will replace strings between * with the following values : y : year of the decision in UTC mo : month of the decision in UTC d : day of the decision in UTC h : hour of the decision in UTC mi : minute of the decision in UTC s : second of the decision in UTC ms : millisecond of the decision in UTC plate : the plate (? will be replaced with !) reliability : reliability context : context (\| will be replaced with !) It is possible to specify directories, that will automatically be created. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability.jpg. Note that during file transfert, the file name is postfixed with ~. It is renamed correctly at the end of the transfert. You should not try to get a file if it is postfixed with ~.
exportContext	If true, the sensor will push 2 JPEG images, one from each camera. Default is false
contextFileName	Context camera JPEG image file name. You can use the same values as for filename. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability_context.jpg.

msg/config/network/ftp/servers/server1

Second server configuration

enabled	If true, the sensor will push decisions on this server.
address	FTP server address. Can be an IP address or an host name
port	FTP server port. If not specified, the default value is used (21 for FTP and FTPS, 22 for SFTP)
login	Login
password	Password
protocol	FTP server protocol. Default value is FTP : ftp : File Transfer Protocol ftps : File Transfer Protocol Secure : using explicit SSL secure mode to connect sftp : SSH File Transfer Protocol
retryCount	If a file cannot be pushed to the server, the sensor will retry until this counter is reached. Default value is 3.
retryDelay_ms	Time waited, in ms, between retries. Default value is 30000 ms.
fileName	Name of generated files. The sensor will replace strings between * with the following values : y : year of the decision in UTC mo : month of the decision in UTC d : day of the decision in UTC h : hour of the decision in UTC mi : minute of the decision in UTC s : second of the decision in UTC ms : millisecond of the decision in UTC plate : the plate (? will be replaced with !) reliability : reliability context : context (\| will be replaced with !) It is possible to specify directories, that will automatically be created. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability.jpg. Note that during file transfert, the file name is postfixed with ~. It is renamed correclty at the end of the transfert. You should not try to get a file if it is postfixed with ~.
exportContext	If true, the sensor will push 2 JPEG images, one from each camera. Default is false
contextFileName	Context camera JPEG image file name. You can use the same values as for filename. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability_context.jpg.

msg/config/network/ftp/servers/server2

Third server configuration

enabled	If true, the sensor will push decisions to this server.
address	FTP server address. Can be an IP address or an host name
port	FTP server port. If not specified, the default value is used (21 for FTP and FTPS, 22 for SFTP)
login	Login
password	Password
protocol	FTP server protocol. Default value is FTP : ftp : File Transfer Protocol ftps : File Transfer Protocol Secure : using explicit SSL secure mode to connect sftp : SSH File Transfer Protocol
retryCount	If a file cannot be pushed to the server, the sensor will retry until this counter is reached. Default value is 3.
retryDelay_ms	Time waited, in ms, between retries. Default value is 30000 ms.
fileName	Name of generated files. The sensor will replace strings between * with the following values : y : year of the decision in UTC mo : month of the decision in UTC d : day of the decision in UTC h : hour of the decision in UTC mi : minute of the decision in UTC s : second of the decision in UTC ms : millisecond of the decision in UTC plate : the plate (? will be replaced with !) reliability : reliability context : context (\| will be replaced with !) It is possible to specify directories, that will automatically be created. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability.jpg. Note that during file transfert, the file name is postfixed with ~. It is renamed correclty at the end of the transfert. You should not try to get a file if it is postfixed with ~.
exportContext	If true, the sensor will push 2 JPEG images, one from each camera. Default is false
contextFileName	Context camera JPEG image file name. You can use the same values as for filename. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability_context.jpg.

msg/config/network/ftp/servers/server3

Fourth server configuration

enabled	If true, the sensor will push decisions on this server.
address	FTP server address. Can be an IP address or an host name
port	FTP server port. If not specified, the default value is used (21 for FTP and FTPS, 22 for SFTP)
login	Login
password	Password
protocol	FTP server protocol. Default value is FTP : ftp : File Transfer Protocol ftps : File Transfer Protocol Secure : using explicit SSL secure mode to connect sftp : SSH File Transfer Protocol
retryCount	If a file cannot be pushed to the server, the sensor will retry until this counter is reached. Default value is 3.
retryDelay_ms	Time waited, in ms, between retries. Default value is 30000 ms.
fileName	Name of generated files. The sensor will replace strings between * with the following values : y : year of the decision in UTC mo : month of the decision in UTC d : day of the decision in UTC h : hour of the decision in UTC mi : minute of the decision in UTC s : second of the decision in UTC ms : millisecond of the decision in UTC plate : the plate (? will be replaced with !) reliability : reliability context : context (\| will be replaced with !) It is possible to specify directories, that will automatically be created. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability.jpg. Note that during file transfert, the file name is postfixed with ~. It is renamed correclty at the end of the transfert. You should not try to get a file if it is postfixed with ~.
exportContext	If true, the sensor will push 2 JPEG images, one from each camera. Default is false
contextFileName	Context camera JPEG image file name. You can use the same values as for filename. If this attribute is empty, the default filename is ymod_hmisms_plate_context_reliability_context.jpg.

RTSP

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

The video stream can be streamed with RTSP protocol. It has to be activated on the LPR unit, with VSS. You can also change the listening port.

The RTSP server supports sending data with RTP and RTP/RTSP.

Note that only the video stream can be sent through RTSP protocol. No data, no plate will be sent.

msg/config/network/rtsp

It is possible to get the video stream from the sensor with a standard RTSP stream. RTSP listening port can be changed.
The address to use is rtsp://sensorIP/0 .

port	Listening port

Relay (IO)

The LPR units can use a relay (in or out) to send or receive events.

Relay out

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

Relay in

Available on :	legacy	VPK4	NPK3	MPK3	PPK3	NPK5	MPK5	VPK5	CTK5

Configuration

The configuration for Relay is in config/io :

msg/config/io

msg/config/io/input

Configuration of the input signal (IO in). These parameters are useful if you use the IO through the sensor, of if trigger on IO is used.

minDuration_ms

Minimum duration of the pulse (in ms) before IO in state is considered as changed. This is useful to avoid signal rebounds.

msg/config/io/defaultImpulse

Configuration of the default output impulse, sent when the 'openBarrier' message is received by the sensor, or when stand alone operating is activated

pulseMode	Pulse mode : falling : Falling edge rising : Rising edge
duration_ms	duration of the pulse (in ms).

Tools

SURVISION provides a set of tools which can be very useful for software integrators.

All there tools can be downloaded on my.survision.

VSS

VSS is the configuration tool for SURVISION LPR units. It is developped on the CDK and mainly uses CDKMsg structures.

It is very useful to developers because it can:

show in real time LPR unit's decisions
view and record video stream (to replay it in the simulator)
get the LPR unit's XSD and the associated documentation
save all received messages in .cdkmsg format (decisions, configuration...)
request stored events
send custom CDKMsg to the LPR unit and get the answer

SurvisionSimulator

SurvisionSimulator can simulate all SURVISION LPR units (Visipak4, Micropak2, etc...). With this tool, you can:

Replay a video recorded with VSS or PVTRecorder : the decisions inside the video will be sent as if it was the real LPR unit
Manually send New/Decision/End messages, so you will receive these messages exactly when you're ready for them
Execute a script, to replay some specific actions
Synchronize the simulator with an external application (with the script server) so the events will be sent synchronized with other equipments needs

PVT

PVT is the SURVISION performance validation tool. It can record SURVISION LPR units video stream and events in a single REC file, and reads it with PVTPlayer.

It can help developers create "real" video files that can be replayed in the simulator.

CDKMsgEditor

CDKMsgEditor is a small tool that opens .cdkmsg files, and show them in a easily reading tree. You can also edit opened files.

CDK Toolbox

The CDK toolbox is a C library that contains some additionnal features to the CDK, like video decoding with FFMpeg.

It is given with its source code and is free of use.