HALO Workshop – Implementation Task Sheet

Objective

Implement a battery charging supervision application on the provided AMP QEMU platform using both a classical approach and a HALO-based approach.

What is already provided

QEMU platform setup
boot and cores/harts startup
Zephyr, FreeRTOS, Bare-Metal, and Linux application skeletons
IPC runtime / shared memory infrastructure
UART console for Linux
Virtual sensors / peripherals with query APIs
All charging logic and state management
build and run scripts

Hart is alias for Core in RISC-V terminology. The platform has 4 harts/cores, each running a different OS or bare-metal code.

What you must implement

Hart1 / Zephyr — SensorFusion

read the sensor values
aggregate them into SensorFrameIf
periodically publish SensorFrameIf at 100ms intervals

Hart2 / FreeRTOS — ChargeController

consume SensorFrameIf
use provided functions for charging decisions
publish ChargeCommandIf and ChargeStatusIf at 200ms intervals
consume OperatorCommandIf if an operator command is received

Hart3 / Bare-metal — SafetyMonitor

consume ChargeCommandIf
use provided functions to check final safety behavior
publish SafetyStateIf at 200ms intervals

Hart4 / Linux — Supervisor

receive UART console commands
use provided functions to parse user commands
convert them into OperatorCommandIf and publish it to ChargeController at 500ms intervals
consume ChargeStatusIf and SafetyStateIf
use provided functions to print state and logs to console

Interfaces you must use

Interface	Write by	Read by	Purpose	Physical Address Range	Virtual Address Range (Linux OS)
`SensorFrameIf`	SensorFusion	ChargeController	periodic measurements	0x80340000 - 0x80340200 (512 bytes)	/
`ChargeCommandIf`	ChargeController	SafetyMonitor	charging command	0x80341000 - 0x80341200 (512 bytes)	/
`ChargeStatusIf`	ChargeController	Supervisor	controller status	0x80342000 - 0x80342040 (64 bytes)	get_external_buffer(offset)
`SafetyStateIf`	SafetyMonitor	Supervisor	safety state	0x80343000 - 0x80343040 (64 bytes)	get_external_buffer(offset)
`OperatorCommandIf`	Supervisor	ChargeController	structured internal command	0x80344000 - 0x80344010 (16 bytes)	get_external_buffer(offset)

Minimum interface contents

SensorFrameIf

battery voltage (unsigned int battery_voltage_mv = 0)
charge current (int charge_current_ma = 0)
battery temperature (float battery_temp_c = 0.0)
breaker state (bool breaker_closed = False)
fault/status flags (unsigned int fault_flags = 0)

fault_flags definition (bitmask, uint32):

bit 0 (0x01): over-temperature
bit 1 (0x02): over-current
bit 2 (0x04): over-voltage
bit 3 (0x08): undervoltage
bit 4 (0x10): breaker open/tripped
bit 5 (0x20): sensor invalid/stale
bits 6-31: reserved (must be 0 for now)

Multiple faults can be set at once using bitwise OR. Example: fault_flags = 0x03 means over-temperature and over-current.

ChargeCommandIf

enable charging (bool enable_charging = False)
current limit (unsigned int current_limit_ma = 0)
voltage limit (unsigned int voltage_limit_mv = 0)
charging mode (string charging_mode = "normal")

Allowed values for charging_mode: "normal", "fast".

ChargeStatusIf

charger state (string charger_state = "idle")
requested current (unsigned int requested_current_ma = 0)
requested voltage (unsigned int requested_voltage_mv = 0)
fault state (unsigned int fault_state = 0)

Allowed values for charger_state: "idle", "charging", "complete", "fault".

SafetyStateIf

safe mode (bool safe_mode = False)
breaker open (bool breaker_open = False)
charging allowed (bool charging_allowed = False)
heartbeat (unsigned int heartbeat_counter = 0)

OperatorCommandIf

command id (unsigned int command_id = 0)
parameter (int command_param = 0)

Allowed values for command_id:

0: no-op (ignore command, keep current state). command_param ignored.
1: start charging. command_param ignored.
2: stop charging. command_param ignored.
3: reset controller/safety state. command_param ignored.
4: set mode normal. command_param ignored.
5: set mode fast. command_param ignored.
6: set current limit in mA. command_param contains the requested current value.
7: set voltage limit in mV. command_param contains the requested voltage value.

For unknown command_id values, ignore the command and set an appropriate fault or log entry.

Example commands

start
stop
reset
mode normal
mode fast
set_current 10
set_voltage 12000

Required scenarios

Nominal scenario

Zephyr reads virtual sensor values
Zephyr publishes SensorFrameIf
FreeRTOS computes charging decision
FreeRTOS publishes ChargeCommandIf and ChargeStatusIf
Bare-metal updates SafetyStateIf
Linux displays current controller and safety state
User sends a UART command
Linux parses it and forwards OperatorCommandIf
FreeRTOS applies the command and updates status

Acceptance checklist

BMS Sensors are read and SensorFrame is published successfully
SensorFrameIf is published periodically
ChargeController computes a charging decision
SafetyMonitor publishes final safety state
Supervisor receives UART commands correctly
Supervisor forwards OperatorCommandIf
At least one command works end-to-end
Status is visible on the console

Workshop Group Allocation

Five groups as G1 through G5.
Group will either start with the classical implementation or the HALO-based implementation first depending on the slip drawn, then switch to the other approach after a fixed time:
- Two slips: Classical -> HALO
- Three slips: HALO -> Classical
Slips will be shuffled thoroughly in view of participants.
One representative from each group will draw exactly one slip.
Allocation will be immediately recorded in a log table with the following fields:
- Group ID
- Assigned order
- Time

HALO system description (HADL)

HALO participants must create their HADL system description files in /workspaces/PhdHaloRSG/halo_dist/hadls. After adding or updating HADL files, compose and generate the HALO framework packages using the VS Code tasks named Halo: Compose and Halo: Generate (available in the workspace Tasks menu).

Guidance: When creating a new HALO system, follow this recommended naming for consistency with other groups:

ADL file: battery_charging_system.adl — Define your system architecture and components first.
IDDL file: battery_charging_system.iddl — Specify your interface data types and structures.
IDL file: battery_charging_system.idl — Define the interface contracts and method integrity (if needed) that you outlined in ADL description.
HML file: battery_charging_system.hml — Add profiles that you outlined in ADL description.

ADL Component Platform & Connection Profile Guidelines

Suggestion: Name each connection after the interface it uses, omitting the If suffix. For example, use SensorTelemetry for SensorFrameIf, ChargingCommand for ChargeCommandIf, etc.

Component Platform Names

When defining components, use the following platform names:

Platform: riscv64_h1_zephyr
Platform: riscv64_h2_freertos
Platform: riscv64_h3_baremetal
Platform: riscv64_h4_linux

Connections and Profile Mapping

SensorTelemetry: SharedMemory
ChargingCommand: SharedMemory
ChargingStatus: BlackBoard
SafetyReport: BlackBoard
OperatorControl: EventChannel

HALO Profiles

Profiles are built-in — use the following directly in your HML connection definitions.

SharedMemory
- Override required attributes: memSize, baseAddress
- Set sizes and addresses to match the interface physical address ranges in this task sheet.
BlackBoard
- Override required attributes: maxPayload, bufferSize, baseAddress
EventChannel
- Override required attributes: eventQueueSize, maxChannels, baseAddress

See the HALO Guide for details and examples of attribute usage: HALO Guide — Profiles.

Tip: HALO-specific code snippets are available in VS Code. Just type hml in a HML file or IDL in IDL file etc. Snippets are defined in .vscode/hadl.code-snippets in this workspace.

See an example HADL workflow in the Getting Started guide: Getting Started — example.

Appendix: Diagrams

System overview