Metadata-Version: 2.4
Name: vehicle_automation
Version: 0.1.0
Summary: Direct and remote backends for vehicle integration tests
Author: Vehicle Automation Team
License: Proprietary
Requires-Python: >=3.11
Description-Content-Type: text/markdown
Requires-Dist: pydantic<3,>=2.7
Requires-Dist: PyYAML>=6.0
Provides-Extra: can
Requires-Dist: python-can>=4.5; extra == "can"
Requires-Dist: cantools>=40; extra == "can"
Provides-Extra: lin
Requires-Dist: ldfparser>=0.25; extra == "lin"
Provides-Extra: mqtt
Requires-Dist: paho-mqtt>=2.0; extra == "mqtt"
Requires-Dist: protobuf>=5; extra == "mqtt"
Provides-Extra: ssh
Requires-Dist: paramiko>=3.4; extra == "ssh"
Provides-Extra: kafka
Requires-Dist: confluent-kafka>=2.5; extra == "kafka"
Provides-Extra: hil
Requires-Dist: pyserial>=3.5; extra == "hil"
Requires-Dist: PyVISA>=1.14; extra == "hil"
Provides-Extra: remote
Requires-Dist: requests>=2.32; extra == "remote"
Requires-Dist: websocket-client>=1.8; extra == "remote"
Provides-Extra: test
Requires-Dist: pytest>=8.0; extra == "test"
Requires-Dist: pytest-mock>=3.14; extra == "test"
Provides-Extra: all
Requires-Dist: vehicle-automation[can,hil,kafka,lin,mqtt,remote,ssh,test]; extra == "all"

# Vehicle Automation

`vehicle-automation` is a standalone test library for CTS/SSTS integration
tests. It provides one `VehicleSession` API with two backends:

- `direct`: interfaces attached to the test workstation.
- `remote`: the existing `vector_auto` HTTP/WebSocket bench server.

The library keeps the legacy action-result shape:
`{"status": bool, "mode": "Pass|Emulated|Skipped", "comment": str}`.

## Quick start

```bash
pip install -e ".[can,mqtt,ssh,remote,test]"
pytest --vehicle-profile profiles/sgw-direct.yaml --vehicle-backend direct
```

Profiles are non-secret. Refer to certificates and private keys through
environment variables such as `${VEHICLE_MQTT_CA}` and `${VEHICLE_SSH_KEY}`.

The package contains no bench credentials, private keys, or production DBC/LDF
matrices. Profiles use absolute or project-relative asset paths so the source
of a matrix is explicit and versioned by the consuming project.

## Project environment preparation (win)

### 1. Create "venv"
```bash
python -m venv .venv
```

### 2. Activate "venv"

#### A - if policies are available:
```bash
.\.venv\Scripts\Activate.ps1
```

#### B - if policies are restricted:
```bash
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\.venv\Scripts\Activate.ps1
```

#### C - for modern CMD env. mode:
```bash
.\.venv\Scripts\activate.bat
```

### 3. Check the env(.venv) is up&running
```bash
python -c "import sys; print(sys.executable)"
```

### 4. UPD pip & set up depenencies
```bash
python -m pip install --upgrade pip
pip install -e ".[test]"
```

## Hardware test suites

Hardware tests are intentionally excluded from normal CI. They require an
explicit profile and `VEHICLE_HARDWARE_ENABLED=1`.

```powershell
# Linux SocketCAN PC + TBOX xwssc capture
$env:VEHICLE_HARDWARE_ENABLED = "1"
pytest tests/hardware/test_mcu_degradation.py -m hardware `
  --vehicle-profile profiles/mcu-degradation-direct.yaml --vehicle-backend direct -s

# ART1 remote bench: CAN UDS VIN read/write load
$env:VEHICLE_HARDWARE_ENABLED = "1"
$env:VEHICLE_UDS_LOAD_ITERATIONS = "300"
pytest tests/hardware/test_sgw_vin_uds_load.py -m "hardware and remote_bench" `
  --vehicle-profile profiles/art1-sgw-remote.yaml --vehicle-backend remote -s
```

Use copies of the example profiles (`*.example.yaml`) and set all referenced
environment variables. The UDS test is CAN UDS despite the legacy
`uds_doip_crash_tests` folder name; security-key processing remains on the
remote `vector_auto` server.
