BDD Charge Point Tester via OCPP J

OCPP Charge Point Tester on Cucumber is a software tool that is designed to simulate a charge point in the Open Charge Point Protocol (OCPP) 1.6 specification using the Cucumber testing framework.

Cucumber is a behavior-driven development (BDD) testing framework that uses the Gherkin language to write test cases in a human-readable format. With the OCPP Charge Point Simulator on Cucumber, test cases can be written in Gherkin and automated using Cucumber's testing framework.

The simulator provides a set of predefined OCPP messages that can be sent and received by the charge point. These messages include basic operations such as boot notification, status notification.

Badges

Publication

You can find the latest version of the release in the Maven Central repository

Technologies used

• Spring Boot
• Cucumber for Java
• OCPP library EuChargetime

Requirements

• Java 17 or higher
• Maven 3.6 or higher

Features

Operations Initiated by Charge Point:

• Authorize
• Boot Notification
• Data Transfer
• Diagnostics Status Notification
• Firmware Status Notification
• Heartbeat
• Meter Values
• Start Transaction
• Status Notification
• Stop Transaction

Operations Initiated by Central System:

• Cancel Reservation
• Change Availability
• Change Configuration
• Clear Cache
• Clear Charging Profile
• Data Transfer
• Get Composite Schedule
• Get Configuration
• Get Diagnostics
• Get Local List Version
• Remote Start Transaction
• Remote Stop Transaction
• Reset
• Send Local List
• Set Charging Profile
• Trigger Message
• Unlock Connector
• Update Firmware

Installation

Install 1/2: Add this to pom.xml:

<dependency>
    <groupId>com.extrawest</groupId>
    <artifactId>bdd-charge-point-tester-via-ocpp-j</artifactId>
    <version>0.1.2</version>
</dependency>

Install 2/2: Run via command line

mvn install

Setup

You need to set port via application.properties. For example:

server.port=3000

Running Tests

1. You need to create a feature file. The file should be located in 'src/test/resources/features'.
2. You need to write a test scenario. Mandatory sequence of the steps is REQUIRED.
3. Run the scenario.

Or you can copy scenario script from the folder. Just change data and run

Mandatory sequence of the steps

• Starting the Central System(CS)
• Waiting for a Charge Point(CP) connection
• Operation test

All text in steps is case-sensitive.

Starting the CS

You can run CS by next steps:

    Given the Central System is started
    Given the Central System is started on "129.39.32.0"

In the first case CS will start on 'localhost'.

In the second - CS will start on specified IP.

Waiting for connection

CS can wait connection with any CP(the first case) or with only specified CP(the second case).

    Given the Charge Point is connected
    Given the Charge Point "ChargePointId" is connected 

Operation test

According to the OCPP documentation, operations are divided into two parts:

• operations initiated by CP
• operations initiated by CS

Also every sent request must receive confirmation response.

The next steps combination is used to test operation, regardless of what data will be received or sent:

initiated by CP without parameters

    When the Central System must receive "ClearCache.req"
    Then the Central System must send confirmation response

initiated by CS without parameters

    When the Central System sends "Reset.req" request to the Charge Point
    Then the Central System receives confirmation

The sending messages will be created with the default values:

Message's parameters

According to OCPP documentation messages can have required and optional parameters.

The next steps combination is used to test operation, with specified parameters:

initiated by CP with parameters

    When the Central System must receive "BootNotification.req" with given data
      | chargePointModel  | CurrentModel  |
      | chargePointVendor | CurrentVendor |
    Then the Central System must send confirmation response with given data
      | currentTime | any |
      | interval    | 60 |
      | status      | Accepted |

initiated by CS with parameters

    When the Central System sends "Reset.req" request to the Charge Point with given data
      | type   | Hard |
    Then the Central System receives confirmation with given data
      | status | any  |

All required fields must be specified, optional fields - optional.

Validation

A receiving message and the specified parameters will be validated according to OCPP documentation.

Assertion

If parameters are specified then all received data in message will be asserted to these parameters.

Wildcard

Parameters can be specified as wildcard(by default 'any').

      | currentTime | any |

For the receiving message this means that current field must have any value(can't be Null).

For the sending message - current field value will be set to default value.

List of available steps:

• Given the Central System is started
• Given the Central System is started on "specified IP"
• Given the Charge Point is connected
• Given the Charge Point "specified Charge Point Id" is connected
• When the Central System must receive "OCPPMessageType.req"
• When the Central System must receive "OCPPMessageType.req" with given data
• Then the Central System must send confirmation response
• Then the Central System must send confirmation response with given data
• When the Central System sends "OCPPMessageType.req" request to the Charge Point
• When the Central System sends "OCPPMessageType.req" request to the Charge Point with given data
• Then the Central System receives confirmation
• Then the Central System receives confirmation with given data
• Then the Central System must receive requested message. Used only with TriggerMessage.req
• Then the Central System must receive requested message with given data. Used only with TriggerMessage.req

Default values

All messages have the default values for every field. These values can be set in application.properties file. If field value is a complicated type(IdTagInfo for example) then you can specify it via JSON string. For example:

- BootNotification.confirmation.interval=60
- Authorize.confirmation.idTagInfo=IdTagInfo{expiryDate="2023-12-31T23:59:59.712244462+02:00[Europe/Kyiv]", parentIdTag=FH7R5JKK6SQ8, status=Accepted}
- Reset.request.requestedMessage=Soft
- TriggerMessage.request.requestedMessage=BootNotification

Scenario example:

• Authorize message
• Boot Notification message
• Data Transfer message
• Meter Values message
• Status Notification message
• Change Availability message
• Clear Cache message
• Get Configuration message
• Reset message
• Trigger Message message