Constructing an OCPP-compliant electrical car cost level operator resolution utilizing AWS IoT Core

The shift from fossil fuels to electrical powered autos is a key element of presidency and industrial commitments to attain net-zero emissions by 2050. It’s projected that the USA alone would require a nationwide community of at the least 500,000 electrical car (EV) chargers by 2030 to help the projected variety of EVs on the highway [1][2]. Globally, governments and industries are partnering to construct tens of millions of public charging and personal fleet charging networks [3].

Putting in and powering the bodily charging infrastructure is simply step one — chargers (Cost Factors or “CP”) have to be constantly monitored and managed by their operators (Cost Level Operators or “CPO”). CPOs are liable for common distant and on-site upkeep, amassing well being metrics, and managing operational configurations. CPOs are additionally liable for making certain that the CPs are suitable with the most recent trade requirements and protocols, like Open Cost Level Protocol (OCPP) and ISO 15118. And all this have to be carried out with safety measures that may help CPs at scale.

This publish demonstrates how AWS providers like AWS IoT Core, Amazon Elastic Container Service (Amazon ECS), and AWS Lambda can be utilized to construct a highly-scalable, low-latency electrical car cost level operator system primarily based on the EV trade commonplace, OCPP.

About AWS IoT Core

AWS IoT Core allows you to join billions of gadgets and route trillions of messages to and from AWS providers with out managing infrastructure. AWS IoT Core handles the heavy-lifting of scaling and message routing—making it simpler for patrons needing to help giant fleets of distant gadgets, like CPs, speaking by publish-and-subscribe patterns. AWS IoT Core natively implements MQTT, HTTPS, and MQTT over WebSockets, and may be tailored to help different protocols, like OCPP.

Overview

Most commercially accessible CPs implement OCPP as a way of bi-directional publish-and-subscribe communication with a CPO. Working a CPO on AWS requires the introduction of an OCPP WebSocket endpoint, with which CPs talk. That endpoint, described right here because the OCPP Gateway, acts as a proxy between OCPP and MQTT, enabling integration with AWS IoT Core and downstream CPO providers constructed on AWS.

The next structure diagram illustrates the high-level end-to-end resolution you’ll construct on this weblog publish.

Determine 1: Cost Level OCPP message proxied to CPO Service by way of one-to-one relationship between WebSocket connection and MQTT subject

Structure

The structure diagram beneath depicts the sources that this resolution will deploy into your account.

Determine 2: OCPP Gateway resolution stack structure

The OCPP Gateway is deployed as an Amazon ECS utility which might run on both AWS Fargate or Amazon Elastic Compute Cloud (EC2). AWS Fargate eliminates the necessity for infrastructure administration and is the popular possibility for this resolution. Containerized functions may be scaled horizontally, permitting the OCPP Gateway to robotically scale up or down because the variety of related CPs adjustments. The lengthy operating nature of ECS duties permits for WebSockets connections to be maintained for prolonged intervals, lowering community site visitors and connection overheads.

A Community Load Balancer (NLB) fronts a number of OCPP Gateway containers. The NLB offers a single, absolutely certified area title (FQDN) that serves because the OCPP endpoint to which CPs provoke connection. Upon connection initiation, the NLB will route the cost level connection to one of many OCPP Gateway situations, which is able to set up the WebSocket connection between itself and the CP.

When a CP establishes a socket reference to an occasion of the OCPP Gateway, that Handler units up an MQTT connection to AWS IoT Core utilizing the CP’s distinctive identifier because the Factor ID. That consumer subscribes to MQTT message subjects related to that CP.

The MQTT consumer carried out by the OCPP Gateway is socket conscious, thereby offering a one-to-one affiliation between the MQTT subscription and the CP. Any messages initiated by the CPO shall be delivered to the MQTT consumer related to the vacation spot CP and forwarded over the socket to that CP. AWS IoT Core is very elastic and can readily scale as extra CPs are on-boarded.

Resolution walk-through

This resolution demonstrates how you need to use AWS to construct a scalable CPO by deploying the OCPP Gateway to combine with AWS IoT Core. The steps beneath will stroll you thru the deployment of an OCPP Gateway into your AWS account, will show how one can simulate CP message, and can present examples of you ways can act on these message utilizing AWS sources.

Stipulations

Confirm that your atmosphere satisfies the next stipulations:

You may have:

1. An AWS account
2. AdministratorAccess coverage granted to your AWS account (for manufacturing, we advocate limiting entry as wanted)
3. Each console and programmatic entry
4. AWS CLI put in and configured to make use of together with your AWS account
5. NodeJS 12+ put in
6. Typescript 3.8+ put in
7. AWS CDK CLI put in
8. Docker put in
9. Python 3+ put in

Put together the CDK

The answer shall be deployed into your AWS account utilizing infrastructure-as-code wih the AWS Cloud Growth Equipment (CDK).

1. Clone the repository:

git clone https://github.com/aws-samples/aws-ocpp-gateway.git

2. Navigate to this venture in your pc utilizing your terminal:

cd aws-ocpp-gateway

3. Set up the venture dependencies by operating this command:

npm set up

4. Set atmosphere variables for CDK to the goal AWS account ID and area the place you want to deploy this stack

Observe: AWS IoT Core is accessible in these AWS areas.

export CDK_DEPLOY_ACCOUNT=targetAccountId (e.g. 12345678910)
export CDK_DEPLOY_REGION=targetRegion (e.g. eu-west-1)

5. (Non-obligatory) Bootstrap AWS CDK on the goal account and regioon

Observe: That is required when you have by no means used AWS CDK earlier than on this account and area mixture. (Extra info on CDK bootstrapping).

npx cdk bootstrap aws://{targetAccountId}/{targetRegion}

(Non-obligatory) Allow WebSockets utilizing TLS with your personal area title

When you have an Amazon Route 53 hosted zone in your account, this resolution can robotically:

• Create subdomain (A Document) gateway.yourdomain.com
• Create an AWS Certificates Supervisor (ACM) SSL certificates for it
• Allow TLS in your gateway wss://gateway.yourdomain.com
• Uncomment this line in /bin/aws-ocpp-gateway.ts and change yourdomain.com with your personal area title (i.e. instance.com)

  // domainName: 'yourdomain.com',

Deploy the answer to your AWS Account

1. Confirm that Docker is operating with the next command:

docker model

Observe: In case you get an error just like the one beneath, then Docker just isn’t operating and have to be restarted:

Can't hook up with the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon operating?

2. Deploy the OCPP Gateway utilizing the next CDK command:

npx cdk deploy

Observe: This step can take about 10 minutes, relying in your pc and community velocity.

3. You possibly can view the progress of your CDK deployment within the CloudFormation console within the chosen area.

Screenshot: AWS CloudFormation stack sources

4. As soon as deployed, pay attention to the AwsOcppGatewayStack.websocketURL worth

Observe: This WebSocket URL is the entry level that shall be set in your CP configurations or within the
EV Cost Level simulator described beneath.

In case you used your personal area, your output will appear to be:

..
Outputs:
AwsOcppGatewayStack.loadBalancerDnsName = gateway.instance.com
👉 AwsOcppGatewayStack.websocketURL = wss://gateway.instance.com
...

In any other case, like this:

...
Outputs:
AwsOcppGatewayStack.loadBalancerDnsName = ocpp-gateway-xxxxxxx.elb.xx-xxxx-x.amazonaws.com
👉 AwsOcppGatewayStack.websocketURL = ws://ocpp-gateway-xxxxxxx.elb.xx-xxxx-x.amazonaws.com
...

Simulating CP connectivity

We’ve got offered the simulate.py Python script that can assist you check and discover the aptitude of the OCPP Gateway and AWS IoT Core with out the necessity for a bodily CP. Different OCPP simulators, like OCPP-2.0-CP-Simulator, may also be used.

Simulation setup

1. In AWS Explorer, choose your area and open AWS IoT Core, All gadgets, Issues. On the Issues tab select Create a issues.
2. Choose Create single factor and select Subsequent
3. Enter a Factor title

Observe: Every EV Cost Level should map to a single IoT Factor. For our check, we’ll set the Factor title as CP1

Screenshot: Creating an IoT Factor

4. Select Subsequent
5. For Gadget certificates, choose Skip making a certificates right now, and select Create factor

Screenshot: Skip the certification creation

6. Navigate to this folder together with your terminal:

cd ev-charge-point-simulator

7. Create a Python digital atmosphere and activate it by operating this command:

python3 -m venv venv && supply venv/bin/activate

8. Set up the Python dependencies by operating:

pip3 set up -r necessities.txt

Simulate an EV cost level boot and heartbeat notification

The Python script simulates some fundamental performance of an EV cost level:

• Sending a BootNotification, together with attributes concerning the CP {hardware}
• Sending Heartbeat messages primarily based on a frequency instructed by the CPO (that is outlined by the interval parameter returned within the response to the BootNotification)

1. Run the Python script utilizing the next command, ensuring to interchange the --url worth with the AwsOcppGatewayStack.websocketURL returned from the cdk deployment:

python3 simulate.py --url {websocket URL generated from the AWS OCPP Stack} --cp-id CP1 

Observe: we’re utilizing --cp-id CP1 which should match the worth of the IoT Factor created above. If the --cp-id doesn’t match the IoT Factor title, the connection shall be rejected by the OCPP Gateway.

A profitable output ought to appear to be this:

(venv) ev-charge-point-simulator % python3 simulate.py --url {websocket URL generated from the AWS OCPP Stack} --cp-id CP1 
INFO:ocpp:CP1: ship [2,"0678cb2a-a7a2-42bc-8037-d01164e77ac6","BootNotification",{"chargingStation":{"model":"ABC 123 XYZ","vendorName":"Acme Electrical Systems","firmwareVersion":"10.9.8.ABC","serialNumber":"CP1234567890A01","modem":{"iccid":"891004234814455936F","imsi":"310410123456789"}},"reason":"PowerUp"}]
INFO:ocpp:CP1: obtain message [3,"0678cb2a-a7a2-42bc-8037-d01164e77ac6",{"currentTime":"2023-02-16T19:00:18.630818","interval":10,"status":"Accepted"}]
INFO:root:CP1: related to central system
INFO:root:CP1: heartbeat interval set to 10
INFO:ocpp:CP1: ship [2,"9b7933a7-5216-496d-9bb0-dae45014bb98","Heartbeat",{}]
INFO:ocpp:CP1: obtain message [3,"9b7933a7-5216-496d-9bb0-dae45014bb98",{"currentTime":"2023-02-16T19:00:19.073675"}]

This alternate represents a profitable simulation of a CP, first sending a BootNotification, adopted by subsequent Heartbeat on the specified interval. The output contains each the simulated OCPP message despatched from the CP to AWS IoT (prefixed ship) and the response obtained from AWS (prefixed obtained message).

2. To simulate with a unique CP, set a unique worth for the --cp-id argument.

Observe: if the --cp-id worth doesn’t have a correspondent IoT Factor the OCPP Gateway will reject the connection. Right here is an unsuccessful instance passing --cp-id CP2, which is not registered as a Factor in IoT:

(venv) ev-charge-point-simulator % python3 simulate.py --url {websocket URL generated from the AWS OCPP Stack} --cp-id CP2 
INFO:ocpp:CP2: ship [2,"32dc5b6e-77b0-4105-b217-28e20b579ecc","BootNotification",{"chargingStation":{"model":"ABC 123 XYZ","vendorName":"Acme Electrical Systems","firmwareVersion":"10.9.8.ABC","serialNumber":"CP1234567890A01","modem":{"iccid":"891004234814455936F","imsi":"310410123456789"}},"reason":"PowerUp"}]
ERROR:root:CP2: obtained 1008 (coverage violation) Cost Level CP2 not registered as an IoT Factor; then despatched 1008 (coverage violation) Cost Level CP2 not registered as an IoT Factor

Monitor OCPP exercise within the AWS Console

Messages from and to the CP are brokered by AWS IoT Core. These messages make the most of the MQTT publish-and-subscribe protocol. You possibly can see these messages within the console.

1. 1. In AWS Explorer, choose your area and open AWS IoT Core, MQTT check consumer
   2. Within the check consumer, choose the Subscribe to a subject tab, and subscribe to those two subjects by getting into these values within the Subject filter:

a. To view all messages from CP to AWS

+/in

b. To view all messages from AWS to CP

+/out

Screenshot: Subscribe to Matters

3. Run the Python script to simulate a CP and watch the messages within the MQTT check consumer

Monitor EV Cost Level {hardware} attributes in system shadows

When a CP sends a BootNotification, its {hardware} attributes are saved in a Gadget Shadow related to the IoT Factor. You possibly can see these attributes within the console.

1. In AWS Explorer, choose your area and open AWS IoT Core, All gadgets, Issues
2. Toggle the verify field in opposition to the Factor created beforehand
3. Choose the Gadget Shadows tab.
4. Choose the Basic Shadow system shadow title hyperlink to see the Gadget Shadow doc and the {hardware} attributes reported by the EV Cost Level:

{
  "state": {
    "reported": {
      "chargingStation": {
        "mannequin": "ABC 123 XYZ",
        "vendorName": "Acme Electrical Programs",
        "firmwareVersion": "10.9.8.ABC",
        "serialNumber": "CP1234567890A01",
        "modem": {
          "iccid": "891004234814455936F",
          "imsi": "310410123456789"
        }
      },
      "cause": "PowerUp"
    }
  }
}

Screenshot: IoT Factor shadow doc

5. Simulate totally different CP {hardware} attributes by passing these arguments into the simulate.py script and confirm their have an effect on on the Gadget Shadow:

• --cp-serial – to set the serial quantity
• --cp-model – to set the mannequin identification
• --cp-version – to set the firmware model
• --cp-vendor – to set the seller title

Conclusion

On this publish, you realized how AWS Providers can be utilized to construct a highly-scalable, low-latency CPO. Utilizing AWS Fargate, you deployed the OCPP Gateway, an OCPP-to-MQTT proxy, which allowed you to reap the benefits of AWS IoT Core’s managed routing and scaling performance to deploy and function your Cost Level Operator resolution on AWS. You realized how Guidelines for AWS IoT can be utilized to filter and route messages from the EV cost level to downstream AWS providers like Amazon DynamoDB and AWS Lambda to create customized reporting and automatic workflows.

The answer and the pattern code have been made accessible as open-source and may be readily tailored to your particular enterprise wants.

We hope you discovered this publish informative and the walk-through useful. As all the time, AWS welcomes suggestions. Please be happy to attach/message the authors by their LinkedIn profiles embody beneath.

(Non-obligatory) Extra issues to strive your self

This part offers some urged simulations and checks you’ll be able to strive your self to raised recognize the artwork of the attainable because it pertains to constructing an OCPP-compliant CPO on AWS.

Load testing

AWS IoT Core is a totally managed, extremely elastic service that scales to help tens of millions of Issues. The OCPP Gateway makes use of auto-scaling to robotically scale-up as your fleet of CPs grows.

1. Utilizing a load testing instrument or the included Apache JMeter configuration, simulate a load of hundreds of CPs
2. In AWS Explorer, choose your area and open Elastic Container Service
3. Beneath Clusters open the hyperlink of the cluster created by the OCPP Gateway stack (shall be prefixed AwsOcppGatewayStack)
4. Choose the Metrics tab
5. Watch how the variety of duties will increase from one to 2, and so on. as your load will increase.

Auto-scaling is configured to set off when the common CPU utilization exceeds 60% — you’ll be able to drive extra load or lower this threshold to check the have an effect on.

In case you are utilizing JMeter or comparable load tester be cautious of the variety of threads (Issues) you create and length you run your check for. The answer will readily scale to many hundreds of Issues and can run for indefinite intervals of time, which can lead to sudden fees in your AWS account. We recommend utilizing the load check to check scalability, however to halt the check shortly to scale back prices.

Guidelines for AWS IoT

Guidelines for AWS IoT can be utilized to filter MQTT messages and route them to different providers in AWS. Create a brand new rule to seize Heartbeat messages and report them in a DynamoDB desk for a final recognized occasion.

1. In AWS Explorer, choose your area and open DynamoDB
2. Choose Create desk
3. Present the Desk title chargePointHeartbeat and set the Partition key to chargePointId
4. Select Create desk
5. In AWS Explorer, choose your area and open AWS IoT Core, Message routing, Guidelines
6. Choose Create Rule
7. Present the Rule title chargePointHeartbeat and select Subsequent
8. Enter the next into the SQL assertion and select Subsequent

SELECT 
  subject(1) AS chargePointId,
  timestamp() AS lastTimestamp
FROM '+/in'
WHERE get(*, 2) = 'Heartbeat'

9. For Motion 1, select DynamoDBv2

Screenshot: IoT Rule SQL assertion

9. Choose the Amazon DynamoDB desk created above for Desk title

Screenshot: IoT Rule motion

10. Choose Create new function, present the Function title
    chargePointHeartbeat, select Create
11. Select Subsequent and Create
12. Navigate again to DynamoBD and choose Tables, Discover Gadgets
13. For Tables, select the DynamoDB desk created beforehand
14. Run the Python script to simulate a CP and watch as heartbeat are added and replace within the DynamoDB desk

Connection dealing with

A single CP ought to solely keep one connection to 1 OCPP Gateway, in any other case routing of responses from the CPO to the best connection could also be affected. You possibly can simulate a reconnection try.

1. (Non-obligatory) In case you don’t have already got it, obtain and set up the wscat utility
2. Open a terminal home windows and set up a WebSocket connection:

wscat -c {AwsOcppGatewayStack.websocketURL}/CP1 -s ocpp2.0.1
Linked (press CTRL+C to give up)
>

3. In a second terminal window run the identical command, making an attempt to create one other connection utilizing the identical CP, e.g.
   CP1
4. As soon as this new connection is established you’ll see that the prior connection is robotically closed:

Disconnected (code: 1000, cause: "")

5. Testing a reference to a CP that isn’t configured as an IoT Factor will end result within the connection try being rejected:

wscat -c {AwsOcppGatewayStack.websocketURL}/CPX -s ocpp2.0.1
Linked (press CTRL+C to give up)
Disconnected (code: 1008, cause: "Cost Level CPX not registered as an IoT Factor")

Clear up

When you find yourself completed operating simulations, deactivate the Python digital atmosphere (venv) by executing this command in your terminal:

deactivate

You possibly can take away the OCPP Gateway Stack and all of the related sources created in your AWS account by operating the next command:

npx cdk destroy

In regards to the authors

This publish is part of a broader effort to help the OCPP protocol on AWS. Particular due to David Goehrig, Sergey Pugachev, Clement Rey, and Ozan Cihangir for his or her contributions to this effort.