Bundles

What constitutes a bundle, and why is it the default distribution method for Josev?

Some part of Josev uses Python. Python is an interpreted language, where instructions are executed directly by an interpreter program, rather than being compiled into machine code beforehand. In interpreted languages, each statement in the source code is translated into machine code and executed by the interpreter at runtime. As we refrain from distributing our source code, we necessitated a method to convert our interpreted code into a compiled package suitable for execution on embedded systems. This is where bundles come into play.

The Unified Bundle is a standalone pack conformed by all the microservices composing the Josev Stack, plus a Python interpreter and all the required dependencies. This pack is presented to the user as a binary that could be executed by any Linux compatible libc implementation.

The Josev Pro Unified Bundle offers an ideal solution tailored for Charging Station manufacturers seeking to streamline their operations without grappling with the intricacies of software, protocols, and nuanced use case implementations.

How about if I want to run Josev microservices as independent Linux Services?

We also offer a Normal bundle, a modular solution derived from the Unified Bundle, where each service is independently packaged with its own interpreter. While offering a more isolated approach, this option may incur additional disk space usage. The bundles may contain the following Python interpreter versions:

3.9
3.10
3.11

The filename of each artifact includes:

The Josev Pro release version
The target architecture
The Python interpreter version used
The glibc version used

What if my Charging Station OS has it’s own Python interpreter?

If you’re system already contains Python, we can strip the Python interpreter from our bundles and so reduce the size of the bundle.

I already have some parts of my stack. Is possible to only get one or two microservices that I’m missing from Josev?

As Josev stack is not monolithic, we can create customized versions that selectively incorporates specific microservices from our stack. This empowers manufacturers to implement only the software components they require, tailored to their unique needs and preferences. Please take into account that the system requirements of the software may vary depending on the services needed. i.e. some bundles may require Python 3.10, others may not require Python at all, etc.

How can I get request my tailored made version of Josev?

For further assistance in these scenarios, we recommend reaching out to us directly. Our team is ready to craft a solution tailored to your specific requirements.

Notes about System Requirements

Josev requires an Operating System

Josev is not engineered to function on bare metal, as it depends heavily on infrastructure provided by an operating system. We provide distinct recommendations for development and production environments:

Development: Utilize Ubuntu 22.04 or compatible distributions, alongside glibc (v2.28 or later) as the C language implementation.
Production: Deploy a Yocto instance utilizing a glibc recipe.

Note: most of Josev services work on MacOS, with the notable exception of the SLAC service, which exclusively works on Linux.

Disk and RAM footprint

The disk space occupied by the stack depends on the preferred flavor.

The following tables summarize the footprint in an NXP I.MX 6ULL (armv7) chip that supports the Josev stack and can be used as reference.

🐍 Python executables bundles

	Normal Bundle	Unified bundle
RAM (peak)	~250 MB	~250 MB
Disk space	~112.9 MB	~50.3 MB

🦀 Rust binaries

Target	CPU [%]	RAM [MB]	Disk space [MB]
armv7 (NXP 6ULL)	7-10	~20	5.3
armv7 (NXP 6ULL) + openssl	7-10	~20	7.3

The option with openssl, means that the binary was compiled statically linking openssl to it.

The CPU usage is a reference and at peak can reach more than 50% of its capacity, which happens during Authorization loop scenarios, when the station is waiting for authorization to go through. This case is momentaneous and as soon as the Authorization is finished, the CPU % stabilizes around the values in the table.

GreenPHY Transceivers

The board where the SOC is embedded must also contain the control pilot (CP) circuit as described in IEC 61851-1. The basic CP circuit must also be connected to a HomePlug GreenPHY chip for modulation and demodulation of the signals exchanged between the EV and the EVSE, as described in ISO 15118-3 document. Furthermore, on the Linux user space level, we require that the link to the HomePlug GreenPHY chip is exposed as a regular network interface (via SPI/I2C drivers) and that it can be used by our services to open network sockets.

Examples of supported Transceivers can be found here