From 72c51d5ee6f5a42e792693eec9b014c66aee59e0 Mon Sep 17 00:00:00 2001 From: openhands Date: Thu, 6 Nov 2025 19:39:35 +0000 Subject: [PATCH] Clean up repository by removing legacy files and temporary documents Removed: - Temporary test databases (*.db files) - Coverage files (.coverage) - Legacy planning documents (COMPLETION, SUMMARY, PLAN, VERIFICATION files) - Duplicate test files (_debug, _direct, _fast, _v2, _fix variants) - Temporary Python files (_modified.py) - Redundant documentation files Kept essential documentation: - README.md, QUICKSTART.md, SECURITY.md - Core documentation in docs/ directory - Essential deployment guides --- .coverage | Bin 53248 -> 0 bytes DASHBOARD_COMPLETION.md | 212 ------- DASHBOARD_TESTING.md | 202 ------ DEPLOYMENT.md | 299 --------- DEPLOYMENT_GUIDE.md | 296 --------- DEPLOYMENT_TESTING.md | 204 ------ FINAL_TEST_SUMMARY.md | 138 ----- FLEXIBLE_DATABASE_CLIENT_SUMMARY.md | 120 ---- IMPLEMENTATION_PLAN.md | 616 ------------------- PHASE5_ACTUAL_VERIFICATION.md | 150 ----- PHASE5_SUMMARY.md | 157 ----- PHASE5_VERIFICATION.md | 109 ---- PHASE6_COMPLETION_SUMMARY.md | 74 --- PHASE7_COMPLETION.md | 176 ------ PHASE_2_COMPLETION_SUMMARY.md | 101 --- PHASE_3_COMPLETION_SUMMARY.md | 163 ----- POSTGRESQL_ANALYSIS.md | 82 --- PROJECT_COMPLETION.md | 261 -------- QUICK_START.md | 141 ----- REMOTE_DASHBOARD_DEPLOYMENT_SUMMARY.md | 77 --- REMOTE_DEPLOYMENT_SUMMARY.md | 85 --- SIMPLIFIED_WORKFLOW.md | 157 ----- TESTING_STRATEGY.md | 110 ---- TEST_ENVIRONMENT.md | 318 ---------- TEST_FAILURES_INVESTIGATION_SUMMARY.md | 102 --- TEST_INVESTIGATION_SUMMARY.md | 151 ----- TEST_RESULTS_SUMMARY.md | 163 ----- src/discovery/protocol_discovery_modified.py | 344 ----------- test_config_manager_add.db | Bin 61440 -> 0 bytes test_config_manager_delete.db | Bin 61440 -> 0 bytes test_config_manager_load.db | Bin 61440 -> 0 bytes test_config_manager_update.db | Bin 61440 -> 0 bytes test_discovery_debug.py | 56 -- test_discovery_direct.py | 35 -- test_discovery_fast.py | 40 -- test_opcua_endpoints_v2.py | 84 --- test_opcua_fix.py | 82 --- 37 files changed, 5305 deletions(-) delete mode 100644 .coverage delete mode 100644 DASHBOARD_COMPLETION.md delete mode 100644 DASHBOARD_TESTING.md delete mode 100644 DEPLOYMENT.md delete mode 100644 DEPLOYMENT_GUIDE.md delete mode 100644 DEPLOYMENT_TESTING.md delete mode 100644 FINAL_TEST_SUMMARY.md delete mode 100644 FLEXIBLE_DATABASE_CLIENT_SUMMARY.md delete mode 100644 IMPLEMENTATION_PLAN.md delete mode 100644 PHASE5_ACTUAL_VERIFICATION.md delete mode 100644 PHASE5_SUMMARY.md delete mode 100644 PHASE5_VERIFICATION.md delete mode 100644 PHASE6_COMPLETION_SUMMARY.md delete mode 100644 PHASE7_COMPLETION.md delete mode 100644 PHASE_2_COMPLETION_SUMMARY.md delete mode 100644 PHASE_3_COMPLETION_SUMMARY.md delete mode 100644 POSTGRESQL_ANALYSIS.md delete mode 100644 PROJECT_COMPLETION.md delete mode 100644 QUICK_START.md delete mode 100644 REMOTE_DASHBOARD_DEPLOYMENT_SUMMARY.md delete mode 100644 REMOTE_DEPLOYMENT_SUMMARY.md delete mode 100644 SIMPLIFIED_WORKFLOW.md delete mode 100644 TESTING_STRATEGY.md delete mode 100644 TEST_ENVIRONMENT.md delete mode 100644 TEST_FAILURES_INVESTIGATION_SUMMARY.md delete mode 100644 TEST_INVESTIGATION_SUMMARY.md delete mode 100644 TEST_RESULTS_SUMMARY.md delete mode 100644 src/discovery/protocol_discovery_modified.py delete mode 100644 test_config_manager_add.db delete mode 100644 test_config_manager_delete.db delete mode 100644 test_config_manager_load.db delete mode 100644 test_config_manager_update.db delete mode 100644 test_discovery_debug.py delete mode 100644 test_discovery_direct.py delete mode 100644 test_discovery_fast.py delete mode 100644 test_opcua_endpoints_v2.py delete mode 100644 test_opcua_fix.py diff --git a/.coverage b/.coverage deleted file mode 100644 index 7010a3442704fb8dcf99d95c48ce10f0d14bd509..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 53248 zcmeI)O>YxN7zglOJJ_*fYg19QiXxP`v>_#qv3jW59w2RVh>ApMQKhO9X1pFJ3*KF` zyC%t@stlEoQ2Pz4s>gl-I9B}xrTqpya^lnq6_Duj?CkmlV#EQ7kp5S(v)-MVedafB zeo6er`Lk}UL?;M68H;y~dBZe~GeQ`KQKDOwZrN6(otf+b{Wiz;r|p)EwOemituKvA z;RnOISUqReDnC}=p8K=nm2S=bRFox$PGExo1Rwx`|F^*4e5GhFEST57iDj#+;!rv& z)c4hoKi^otuput2e{^<3=wsqUSVBl! zywK4xTIx9AT9Tjlnr@qN#cGR+=!LE)!##0D?X4yW(yPU4H`WKJ5an+9oI;#Pv#*Fy zbyTQ)M@2e{6K;E@ymI5)a?w6|)V!&ZI?2$XpSg+J(1B4^Hak?16NGJ!z7)M8aSC0eHb^WB8e&oh(;0v{@oPMm@`&Mw3(Xx&3#%n`mUE&H|(mB&> zjp>Xs?~^l4o@VY)aDI@njxzG4DRUCD-}hQXe!1`UxN#_lzHl5&%Q-D?9Hft!BPyO)eTyceJ$xRk)i=Yb3vA@)At=7 zDiPPg39hM7ZmG5OtezHLbw{GE(q#;XluwDTKCu~bfEL%Z8PWmrDOu8qpJ)?Ma z0i(y6J*8SnlGE`1EQlhPmQ`N1q7Sm8VtHFeJPSq3q7?*PC4Id%P>#)ruIWZ1iQ(B* z>GY_KXphU-y0)Celr1hi&0nBFmyIvl@jU6b)Afp%VO=WC{X97NI(ibJjAEGvWkf^t zsWP)d)3ZEdW#zB+$b?JvWLpn+Zj`YSced3t#p%`P6B(=6^_1WwNia#r+L4iPLPaNO zEnQj8Kd&2bYc(5u&##ha`KjDs$t>C@Pnv^%IvDjl(~M|Q_hc4!`Y<=qNuD}6>M!SL z!lh?BQWAxo7$*D0^?3w+ahWY7;b2tWV=5P$##AOHafKmY;| zfB*yzpFrNsnMHp6pR@iltow9_4FV8=00bZa0SG_<0uX=z1Rwx`*HWO8%OAJ0zwkIU zZ{`;l(!T+CZ>`Z-J5{Dy<*a*#byAM`*dPD_2tWV=5P$##AOHafKmY;|I8XwcGXuNyQeOY#`~MD9!y*_6KmY;|fB*y_ z009U<00Izzz{?iMn|Y(EKmUJhSdU+J@hA@h5P$##AOHafKmY;|fB*y_0D*%bkk403 z`t$$0hIRKKM1&Y1009U<00Izz00bZa0SG_<0uXosfx0z{}fB*y_009U<00Izz z00ba#$OLBSt%Bt9fBn9|A*&s#0|5v?00Izz00bZa0SG_<0uX?}P=G)G$Ls$g2X-I; z0SG_<0uX=z1Rwwb2tWV=hf;w5{~xda4`tJ$QV@Uu1Rwwb2tWV=5P$##AOL}(z<*S} Ba#R2S diff --git a/DASHBOARD_COMPLETION.md b/DASHBOARD_COMPLETION.md deleted file mode 100644 index b8ce7c8..0000000 --- a/DASHBOARD_COMPLETION.md +++ /dev/null @@ -1,212 +0,0 @@ -# Interactive Dashboard - COMPLETED โœ… - -## Overview - -We have successfully created a comprehensive interactive dashboard for the Calejo Control Adapter that provides convenient configuration management, system monitoring, and operational controls through a modern web interface. - -## โœ… Completed Dashboard Features - -### 1. Dashboard Architecture & Design -- **Tab-based interface** with intuitive navigation -- **Responsive design** for desktop and mobile devices -- **Modern UI/UX** with clean, professional styling -- **Real-time updates** and status indicators - -### 2. Backend API Integration -- **REST API endpoints** for configuration management -- **Pydantic models** for data validation -- **FastAPI integration** with existing REST server -- **Error handling** and validation responses - -### 3. Frontend Implementation -- **Pure HTML/CSS/JavaScript** (no external dependencies) -- **Modern JavaScript** using Fetch API -- **Responsive CSS** with Flexbox/Grid layouts -- **Interactive forms** with real-time validation - -### 4. Configuration Management -- **Database configuration** (host, port, credentials) -- **Protocol configuration** (OPC UA, Modbus enable/disable) -- **REST API configuration** (host, port, CORS) -- **Monitoring configuration** (health monitor port) -- **Validation system** with error and warning messages - -### 5. System Integration -- **Health monitoring integration** with real-time status -- **Log viewing** with timestamp and level filtering -- **System actions** (restart, backup, health checks) -- **Static file serving** for JavaScript and CSS - -## ๐Ÿš€ Dashboard Features - -### Status Monitoring -- **Application Status**: Overall system health -- **Database Status**: PostgreSQL connection status -- **Protocol Status**: OPC UA and Modbus server status -- **REST API Status**: API endpoint availability -- **Monitoring Status**: Health monitor and metrics collection - -### Configuration Management -- **Load Current**: Load existing configuration -- **Save Configuration**: Apply new settings -- **Validate**: Check configuration validity -- **Real-time Validation**: Port ranges, required fields, security warnings - -### System Logs -- **Real-time Log Display**: Latest system logs -- **Color-coded Levels**: INFO, WARNING, ERROR -- **Timestamp Information**: Precise timing -- **Auto-refresh**: Continuous log updates - -### System Actions -- **Restart System**: Controlled system restart with confirmation -- **Create Backup**: Manual backup initiation -- **Health Checks**: On-demand system health verification -- **View Metrics**: Direct access to Prometheus metrics - -## ๐Ÿ”ง Technical Implementation - -### Backend Components -```python -src/dashboard/ -โ”œโ”€โ”€ api.py # Dashboard API endpoints -โ”œโ”€โ”€ templates.py # HTML templates -โ”œโ”€โ”€ router.py # Main dashboard router -``` - -### Frontend Components -``` -static/ -โ””โ”€โ”€ dashboard.js # Frontend JavaScript -``` - -### API Endpoints -- `GET /api/v1/dashboard/config` - Get current configuration -- `POST /api/v1/dashboard/config` - Update configuration -- `GET /api/v1/dashboard/status` - Get system status -- `POST /api/v1/dashboard/restart` - Restart system -- `GET /api/v1/dashboard/backup` - Create backup -- `GET /api/v1/dashboard/logs` - Get system logs - -## ๐ŸŽฏ User Experience - -### Intuitive Interface -- **Tab-based navigation** for easy access -- **Color-coded status indicators** for quick assessment -- **Form validation** with helpful error messages -- **Confirmation dialogs** for destructive actions - -### Responsive Design -- **Mobile-friendly** interface -- **Touch-friendly** controls -- **Adaptive layout** for different screen sizes -- **Optimized performance** for various devices - -### Real-time Updates -- **Auto-refresh status** every 30 seconds -- **Live log updates** with manual refresh -- **Instant validation** feedback -- **Dynamic status indicators** - -## ๐Ÿ”’ Security Features - -### Authentication & Authorization -- **JWT token integration** with existing security system -- **Role-based access control** for dashboard features -- **Secure credential handling** in configuration forms - -### Input Validation -- **Server-side validation** for all configuration changes -- **Port range validation** (1-65535) -- **Required field validation** with clear error messages -- **Security warnings** for default credentials - -### Security Warnings -- **Default JWT secret key** detection -- **Default API key** detection -- **Default database password** detection -- **Configuration validation** before saving - -## ๐Ÿ“Š Integration Points - -### Health Monitoring -- **Health check endpoints** integration -- **Prometheus metrics** access -- **Component status** monitoring -- **Performance metrics** display - -### Configuration System -- **Settings integration** with existing configuration -- **Environment variable** compatibility -- **Configuration validation** against system requirements -- **Error handling** for invalid configurations - -### Logging System -- **System log access** through API -- **Log level filtering** and display -- **Timestamp formatting** for readability -- **Real-time log updates** - -## ๐Ÿ› ๏ธ Deployment & Access - -### Access URL -``` -http://localhost:8080/dashboard -``` - -or - -``` -http://localhost:8080/ -``` - -### Integration with Docker -- **Static file serving** through FastAPI -- **Port mapping** for dashboard access -- **Health check integration** with container orchestration -- **Configuration persistence** through volumes - -### Browser Compatibility -- **Chrome**: 70+ -- **Firefox**: 65+ -- **Safari**: 12+ -- **Edge**: 79+ - -## ๐ŸŽ‰ Benefits - -### For System Administrators -- **Centralized management** of all system components -- **Real-time monitoring** without command-line access -- **Quick configuration changes** through web interface -- **System health overview** at a glance - -### For Operators -- **Easy access** to system status and logs -- **Simple backup creation** with one click -- **Health check verification** without technical knowledge -- **Mobile access** for remote monitoring - -### For Developers -- **API-driven architecture** for extensibility -- **Modern web technologies** for easy maintenance -- **Comprehensive documentation** for further development -- **Integration points** for custom features - -## ๐Ÿ“ˆ Future Enhancements - -While the dashboard is fully functional, potential future enhancements include: - -1. **Advanced Visualization**: Charts and graphs for metrics -2. **User Management**: Dashboard-specific user accounts -3. **Notification System**: Alert integration -4. **Historical Data**: Configuration change history -5. **Multi-language Support**: Internationalization -6. **Theme Customization**: Dark/light mode support - ---- - -**Dashboard Status**: โœ… **COMPLETED** -**Production Ready**: โœ… **YES** -**Test Coverage**: All components tested and working -**Documentation**: Comprehensive guide created -**Integration**: Fully integrated with existing system \ No newline at end of file diff --git a/DASHBOARD_TESTING.md b/DASHBOARD_TESTING.md deleted file mode 100644 index f8e7545..0000000 --- a/DASHBOARD_TESTING.md +++ /dev/null @@ -1,202 +0,0 @@ -# Dashboard Testing - COMPLETED โœ… - -## Overview - -Comprehensive test suite for the Calejo Control Adapter Dashboard has been successfully created and all tests are passing. - -## โœ… Test Coverage - -### Unit Tests: 29 tests - -#### 1. Dashboard Models (`test_dashboard_models.py`) -- **13 tests** covering all Pydantic models -- Tests default values and custom configurations -- Validates model structure and data types - -**Models Tested:** -- `DatabaseConfig` - Database connection settings -- `OPCUAConfig` - OPC UA server configuration -- `ModbusConfig` - Modbus server configuration -- `RESTAPIConfig` - REST API settings -- `MonitoringConfig` - Health monitoring configuration -- `SecurityConfig` - Security settings -- `SystemConfig` - Complete system configuration - -#### 2. Dashboard Validation (`test_dashboard_validation.py`) -- **8 tests** covering configuration validation -- Tests validation logic for required fields -- Tests port range validation (1-65535) -- Tests security warnings for default credentials -- Tests partial validation with mixed valid/invalid fields - -**Validation Scenarios:** -- Valid configuration with all required fields -- Missing database fields (host, name, user) -- Invalid port numbers (out of range) -- Default credential warnings -- Valid port boundary values -- Partial validation errors -- Validation result structure - -#### 3. Dashboard API Endpoints (`test_dashboard_api.py`) -- **8 tests** covering all API endpoints -- Tests GET/POST operations with mocked dependencies -- Tests error handling and response formats - -**API Endpoints Tested:** -- `GET /api/v1/dashboard/config` - Get current configuration -- `POST /api/v1/dashboard/config` - Update configuration -- `GET /api/v1/dashboard/status` - Get system status -- `POST /api/v1/dashboard/restart` - Restart system -- `GET /api/v1/dashboard/backup` - Create backup -- `GET /api/v1/dashboard/logs` - Get system logs - -### Integration Tests: 6 tests - -#### Dashboard Integration (`test_dashboard_integration.py`) -- **6 tests** covering integration with REST API -- Tests complete configuration flow -- Tests static file serving -- Tests system actions and status integration -- Tests error handling scenarios - -**Integration Scenarios:** -- Dashboard routes availability through REST API -- Static JavaScript file serving -- Complete configuration management flow -- System actions (restart, backup) -- Health monitor integration -- Error handling with invalid configurations - -## ๐Ÿงช Test Architecture - -### Mocking Strategy -- **Settings mocking** for configuration retrieval -- **Validation mocking** for configuration updates -- **Manager mocking** for system components -- **Health monitor mocking** for status checks - -### Test Fixtures -- **TestClient** for FastAPI endpoint testing -- **Mock managers** for system components -- **API server** with dashboard integration - -### Test Data -- **Valid configurations** with realistic values -- **Invalid configurations** for error testing -- **Boundary values** for port validation -- **Security scenarios** for credential warnings - -## ๐Ÿ”ง Test Execution - -### Running All Dashboard Tests -```bash -# Run all dashboard tests -python -m pytest tests/unit/test_dashboard_*.py tests/integration/test_dashboard_*.py -v - -# Run specific test categories -python -m pytest tests/unit/test_dashboard_models.py -v -python -m pytest tests/unit/test_dashboard_validation.py -v -python -m pytest tests/unit/test_dashboard_api.py -v -python -m pytest tests/integration/test_dashboard_integration.py -v -``` - -### Test Results Summary -- **Total Tests**: 35 -- **Passed**: 35 (100%) -- **Failed**: 0 -- **Warnings**: 10 (Pydantic deprecation warnings - not critical) - -## ๐Ÿ“Š Test Quality Metrics - -### Code Coverage -- **Models**: 100% coverage of all Pydantic models -- **Validation**: 100% coverage of validation logic -- **API Endpoints**: 100% coverage of all endpoints -- **Integration**: Full integration flow coverage - -### Test Scenarios -- **Happy Path**: Normal operation with valid data -- **Error Path**: Invalid data and error conditions -- **Boundary Conditions**: Edge cases and limits -- **Security Scenarios**: Credential validation and warnings - -### Test Reliability -- **Isolated Tests**: Each test runs independently -- **Mocked Dependencies**: No external dependencies -- **Consistent Results**: Tests produce consistent outcomes -- **Fast Execution**: All tests complete in under 1 second - -## ๐Ÿš€ Test-Driven Development Benefits - -### Quality Assurance -- **Prevents Regressions**: Changes to dashboard functionality are automatically tested -- **Validates Data Models**: Ensures configuration data structures are correct -- **Verifies API Contracts**: Confirms API endpoints behave as expected - -### Development Efficiency -- **Rapid Feedback**: Tests provide immediate feedback on changes -- **Documentation**: Tests serve as living documentation -- **Refactoring Safety**: Safe to refactor with test coverage - -### Maintenance Benefits -- **Early Bug Detection**: Issues caught during development -- **Configuration Validation**: Prevents invalid configurations -- **Integration Confidence**: Ensures dashboard works with existing system - -## ๐Ÿ” Test Scenarios Detail - -### Model Testing -- **Default Values**: Ensures sensible defaults for all configurations -- **Custom Values**: Validates custom configuration acceptance -- **Data Types**: Confirms proper type handling for all fields - -### Validation Testing -- **Required Fields**: Validates presence of essential configuration -- **Port Ranges**: Ensures ports are within valid ranges (1-65535) -- **Security Warnings**: Detects and warns about default credentials -- **Partial Validation**: Handles mixed valid/invalid configurations - -### API Testing -- **GET Operations**: Tests configuration and status retrieval -- **POST Operations**: Tests configuration updates -- **Error Responses**: Validates proper error handling -- **Response Formats**: Ensures consistent API responses - -### Integration Testing -- **Route Availability**: Confirms dashboard routes are accessible -- **Static Files**: Verifies JavaScript file serving -- **Configuration Flow**: Tests complete configuration lifecycle -- **System Actions**: Validates restart and backup operations -- **Error Handling**: Tests graceful error recovery - -## ๐Ÿ“ˆ Future Test Enhancements - -While current test coverage is comprehensive, potential future enhancements include: - -### Additional Test Types -1. **End-to-End Tests**: Browser automation for UI testing -2. **Performance Tests**: Load testing for dashboard performance -3. **Security Tests**: Penetration testing for security vulnerabilities -4. **Accessibility Tests**: WCAG compliance testing - -### Expanded Scenarios -1. **Multi-user Testing**: Concurrent user scenarios -2. **Configuration Migration**: Version upgrade testing -3. **Backup/Restore Testing**: Complete backup lifecycle -4. **Network Failure Testing**: Network partition scenarios - -### Monitoring Integration -1. **Test Metrics**: Dashboard test performance metrics -2. **Test Coverage Reports**: Automated coverage reporting -3. **Test Result Dashboards**: Visual test result tracking - ---- - -## ๐ŸŽ‰ TESTING STATUS: COMPLETED โœ… - -**Test Coverage**: 35/35 tests passing (100% success rate) -**Code Quality**: Comprehensive coverage of all dashboard components -**Integration**: Full integration with existing REST API -**Reliability**: All tests pass consistently -**Maintainability**: Well-structured, isolated test cases \ No newline at end of file diff --git a/DEPLOYMENT.md b/DEPLOYMENT.md deleted file mode 100644 index be36a78..0000000 --- a/DEPLOYMENT.md +++ /dev/null @@ -1,299 +0,0 @@ -# Calejo Control Adapter - Deployment Guide - -## Overview - -The Calejo Control Adapter is a multi-protocol integration system for municipal wastewater pump stations with comprehensive safety and security features. - -## Quick Start with Docker Compose - -### Prerequisites -- Docker Engine 20.10+ -- Docker Compose 2.0+ -- At least 4GB RAM - -### Deployment Steps - -1. **Clone and configure** - ```bash - git clone - cd calejo-control-adapter - - # Copy and edit environment configuration - cp .env.example .env - # Edit .env with your settings - ``` - -2. **Start the application** - ```bash - docker-compose up -d - ``` - -3. **Verify deployment** - ```bash - # Check container status - docker-compose ps - - # Check application health - curl http://localhost:8080/health - - # Access monitoring dashboards - # Grafana: http://localhost:3000 (admin/admin) - # Prometheus: http://localhost:9091 - ``` - -## Manual Installation - -### System Requirements -- Python 3.11+ -- PostgreSQL 14+ -- 2+ CPU cores -- 4GB+ RAM -- 10GB+ disk space - -### Installation Steps - -1. **Install dependencies** - ```bash - # Ubuntu/Debian - sudo apt update - sudo apt install python3.11 python3.11-venv python3.11-dev postgresql postgresql-contrib - - # CentOS/RHEL - sudo yum install python3.11 python3.11-devel postgresql postgresql-server - ``` - -2. **Set up PostgreSQL** - ```bash - sudo -u postgres psql - CREATE DATABASE calejo; - CREATE USER calejo WITH PASSWORD 'secure_password'; - GRANT ALL PRIVILEGES ON DATABASE calejo TO calejo; - \q - ``` - -3. **Configure application** - ```bash - # Create virtual environment - python3.11 -m venv venv - source venv/bin/activate - - # Install Python dependencies - pip install -r requirements.txt - - # Configure environment - export DATABASE_URL="postgresql://calejo:secure_password@localhost:5432/calejo" - export JWT_SECRET_KEY="your-secret-key-change-in-production" - export API_KEY="your-api-key-here" - ``` - -4. **Initialize database** - ```bash - # Run database initialization - psql -h localhost -U calejo -d calejo -f database/init.sql - ``` - -5. **Start the application** - ```bash - python -m src.main - ``` - -## Configuration - -### Environment Variables - -| Variable | Description | Default | -|----------|-------------|---------| -| `DATABASE_URL` | PostgreSQL connection string | `postgresql://calejo:password@localhost:5432/calejo` | -| `JWT_SECRET_KEY` | JWT token signing key | `your-secret-key-change-in-production` | -| `API_KEY` | API access key | `your-api-key-here` | -| `OPCUA_HOST` | OPC UA server host | `localhost` | -| `OPCUA_PORT` | OPC UA server port | `4840` | -| `MODBUS_HOST` | Modbus server host | `localhost` | -| `MODBUS_PORT` | Modbus server port | `502` | -| `REST_API_HOST` | REST API host | `0.0.0.0` | -| `REST_API_PORT` | REST API port | `8080` | -| `HEALTH_MONITOR_PORT` | Prometheus metrics port | `9090` | - -### Database Configuration - -For production PostgreSQL configuration: - -```sql --- Optimize PostgreSQL for production -ALTER SYSTEM SET shared_buffers = '1GB'; -ALTER SYSTEM SET effective_cache_size = '3GB'; -ALTER SYSTEM SET work_mem = '16MB'; -ALTER SYSTEM SET maintenance_work_mem = '256MB'; -ALTER SYSTEM SET checkpoint_completion_target = 0.9; -ALTER SYSTEM SET wal_buffers = '16MB'; -ALTER SYSTEM SET default_statistics_target = 100; - --- Restart PostgreSQL to apply changes -SELECT pg_reload_conf(); -``` - -## Monitoring and Observability - -### Health Endpoints - -- **Basic Health**: `GET /health` -- **Detailed Health**: `GET /api/v1/health/detailed` -- **Metrics**: `GET /metrics` (Prometheus format) - -### Key Metrics - -- `calejo_app_uptime_seconds` - Application uptime -- `calejo_db_connections_active` - Active database connections -- `calejo_opcua_connections` - OPC UA client connections -- `calejo_modbus_connections` - Modbus connections -- `calejo_rest_api_requests_total` - REST API request count -- `calejo_safety_violations_total` - Safety violations detected - -## Security Hardening - -### Network Security - -1. **Firewall Configuration** - ```bash - # Allow only necessary ports - ufw allow 22/tcp # SSH - ufw allow 5432/tcp # PostgreSQL - ufw allow 8080/tcp # REST API - ufw allow 9090/tcp # Prometheus - ufw enable - ``` - -2. **SSL/TLS Configuration** - ```bash - # Generate SSL certificates - openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes - - # Configure in settings - export TLS_ENABLED=true - export TLS_CERT_PATH=/path/to/cert.pem - export TLS_KEY_PATH=/path/to/key.pem - ``` - -### Application Security - -1. **Change Default Credentials** - - Update JWT secret key - - Change API key - - Update database passwords - - Rotate user passwords - -2. **Access Control** - - Implement network segmentation - - Use VPN for remote access - - Configure role-based access control - -## Backup and Recovery - -### Database Backups - -```bash -# Daily backup script -#!/bin/bash -BACKUP_DIR="/backups/calejo" -DATE=$(date +%Y%m%d_%H%M%S) - -# Create backup -pg_dump -h localhost -U calejo calejo > "$BACKUP_DIR/calejo_backup_$DATE.sql" - -# Compress backup -gzip "$BACKUP_DIR/calejo_backup_$DATE.sql" - -# Keep only last 7 days -find "$BACKUP_DIR" -name "calejo_backup_*.sql.gz" -mtime +7 -delete -``` - -### Application Data Backup - -```bash -# Backup configuration and logs -tar -czf "/backups/calejo_config_$(date +%Y%m%d).tar.gz" config/ logs/ -``` - -### Recovery Procedure - -1. **Database Recovery** - ```bash - # Stop application - docker-compose stop calejo-control-adapter - - # Restore database - gunzip -c backup_file.sql.gz | psql -h localhost -U calejo calejo - - # Start application - docker-compose start calejo-control-adapter - ``` - -2. **Configuration Recovery** - ```bash - # Extract configuration backup - tar -xzf config_backup.tar.gz -C / - ``` - -## Performance Tuning - -### Database Performance - -- Monitor query performance with `EXPLAIN ANALYZE` -- Create appropriate indexes -- Regular VACUUM and ANALYZE operations -- Connection pooling configuration - -### Application Performance - -- Monitor memory usage -- Configure appropriate thread pools -- Optimize database connection settings -- Enable compression for large responses - -## Troubleshooting - -### Common Issues - -1. **Database Connection Issues** - - Check PostgreSQL service status - - Verify connection string - - Check firewall rules - -2. **Port Conflicts** - - Use `netstat -tulpn` to check port usage - - Update configuration to use available ports - -3. **Performance Issues** - - Check system resources (CPU, memory, disk) - - Monitor database performance - - Review application logs - -### Log Files - -- Application logs: `logs/calejo.log` -- Database logs: PostgreSQL log directory -- System logs: `/var/log/syslog` or `/var/log/messages` - -## Support and Maintenance - -### Regular Maintenance Tasks - -- Daily: Check application health and logs -- Weekly: Database backups and cleanup -- Monthly: Security updates and patches -- Quarterly: Performance review and optimization - -### Monitoring Checklist - -- [ ] Application responding to health checks -- [ ] Database connections stable -- [ ] No safety violations -- [ ] System resources adequate -- [ ] Backup procedures working - -## Contact and Support - -For technical support: -- Email: support@calejo-control.com -- Documentation: https://docs.calejo-control.com -- Issue Tracker: https://github.com/calejo/control-adapter/issues \ No newline at end of file diff --git a/DEPLOYMENT_GUIDE.md b/DEPLOYMENT_GUIDE.md deleted file mode 100644 index 6852b61..0000000 --- a/DEPLOYMENT_GUIDE.md +++ /dev/null @@ -1,296 +0,0 @@ -# Calejo Control Adapter - Deployment Guide - -This guide provides comprehensive instructions for deploying the Calejo Control Adapter in on-premises customer environments. - -## ๐Ÿš€ Quick Deployment - -### Automated Deployment (Recommended) - -For quick and easy deployment, use the automated deployment script: - -```bash -# Run as root for system-wide installation -sudo ./deploy-onprem.sh -``` - -This script will: -- Check prerequisites (Docker, Docker Compose) -- Create necessary directories -- Copy all required files -- Create systemd service for automatic startup -- Build and start all services -- Create backup and health check scripts - -### Manual Deployment - -If you prefer manual deployment: - -1. **Install Prerequisites** - ```bash - # Install Docker - curl -fsSL https://get.docker.com -o get-docker.sh - sudo sh get-docker.sh - - # Install Docker Compose - sudo curl -L "https://github.com/docker/compose/releases/download/v2.20.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose - sudo chmod +x /usr/local/bin/docker-compose - ``` - -2. **Deploy Application** - ```bash - # Create directories - sudo mkdir -p /opt/calejo-control-adapter - sudo mkdir -p /var/log/calejo - sudo mkdir -p /etc/calejo - sudo mkdir -p /var/backup/calejo - - # Copy files - sudo cp -r ./* /opt/calejo-control-adapter/ - sudo cp config/settings.py /etc/calejo/ - - # Set permissions - sudo chmod +x /opt/calejo-control-adapter/scripts/*.sh - - # Build and start - cd /opt/calejo-control-adapter - sudo docker-compose build - sudo docker-compose up -d - ``` - -## ๐Ÿงช Testing the Deployment - -### End-to-End Testing - -Test the complete system with mock SCADA and optimization servers: - -```bash -# Run comprehensive end-to-end tests -python test-e2e-deployment.py -``` - -This will: -- Start mock SCADA server -- Start mock optimization server -- Start main application -- Test all endpoints and functionality -- Validate integration between components - -### Individual Component Testing - -```bash -# Test mock SCADA server -python mock-scada-server.py - -# Test mock optimization server -python mock-optimization-server.py - -# Test local dashboard functionality -python test_dashboard_local.py - -# Test deployment health -./validate-deployment.sh -``` - -## ๐Ÿ” Deployment Validation - -After deployment, validate that everything is working correctly: - -```bash -# Run comprehensive validation -./validate-deployment.sh -``` - -This checks: -- โœ… System resources (disk, memory, CPU) -- โœ… Docker container status -- โœ… Application endpoints -- โœ… Configuration validity -- โœ… Log files -- โœ… Security configuration -- โœ… Backup setup - -## ๐Ÿ“Š Mock Systems for Testing - -### Mock SCADA Server - -The mock SCADA server (`mock-scada-server.py`) simulates: -- **OPC UA Server** on port 4840 -- **Modbus TCP Server** on port 502 -- **Real-time process data** (temperature, pressure, flow, level) -- **Historical data trends** -- **Alarm simulation** - -### Mock Optimization Server - -The mock optimization server (`mock-optimization-server.py`) simulates: -- **Multiple optimization strategies** -- **Market data simulation** -- **Setpoint calculations** -- **Cost and energy savings analysis** -- **Confidence scoring** - -## ๐Ÿ”ง Management Commands - -### Service Management - -```bash -# Start service -sudo systemctl start calejo-control-adapter - -# Stop service -sudo systemctl stop calejo-control-adapter - -# Check status -sudo systemctl status calejo-control-adapter - -# Enable auto-start -sudo systemctl enable calejo-control-adapter -``` - -### Application Management - -```bash -# Health check -/opt/calejo-control-adapter/scripts/health-check.sh - -# Full backup -/opt/calejo-control-adapter/scripts/backup-full.sh - -# Restore from backup -/opt/calejo-control-adapter/scripts/restore-full.sh - -# View logs -sudo docker-compose logs -f app -``` - -## ๐Ÿ“ Directory Structure - -``` -/opt/calejo-control-adapter/ # Main application directory -โ”œโ”€โ”€ src/ # Source code -โ”œโ”€โ”€ static/ # Static files (dashboard) -โ”œโ”€โ”€ config/ # Configuration files -โ”œโ”€โ”€ scripts/ # Management scripts -โ”œโ”€โ”€ monitoring/ # Monitoring configuration -โ”œโ”€โ”€ tests/ # Test files -โ””โ”€โ”€ docker-compose.yml # Docker Compose configuration - -/var/log/calejo/ # Application logs -/etc/calejo/ # Configuration files -/var/backup/calejo/ # Backup files -``` - -## ๐ŸŒ Access Points - -After deployment, access the system at: - -- **Dashboard**: `http://:8080/dashboard` -- **REST API**: `http://:8080` -- **Health Check**: `http://:8080/health` -- **Mock SCADA (OPC UA)**: `opc.tcp://:4840` -- **Mock SCADA (Modbus)**: `:502` - -## ๐Ÿ”’ Security Considerations - -### Default Credentials - -The deployment includes security validation that warns about: -- Default database credentials -- Unsecured communication -- Open ports - -### Recommended Security Practices - -1. **Change default passwords** in configuration -2. **Enable authentication** in production -3. **Use SSL/TLS** for external communication -4. **Configure firewall** to restrict access -5. **Regular security updates** - -## ๐Ÿ“ˆ Monitoring and Maintenance - -### Health Monitoring - -```bash -# Regular health checks -/opt/calejo-control-adapter/scripts/health-check.sh - -# Monitor logs -sudo tail -f /var/log/calejo/*.log -``` - -### Backup Strategy - -```bash -# Schedule regular backups (add to crontab) -0 2 * * * /opt/calejo-control-adapter/scripts/backup-full.sh - -# Manual backup -/opt/calejo-control-adapter/scripts/backup-full.sh -``` - -### Performance Monitoring - -The deployment includes: -- **Prometheus** metrics collection -- **Grafana** dashboards -- **Health monitoring** endpoints -- **Log aggregation** - -## ๐Ÿ› Troubleshooting - -### Common Issues - -1. **Application not starting** - ```bash - # Check Docker status - sudo systemctl status docker - - # Check application logs - sudo docker-compose logs app - ``` - -2. **Dashboard not accessible** - ```bash - # Check if application is running - curl http://localhost:8080/health - - # Check firewall settings - sudo ufw status - ``` - -3. **Mock servers not working** - ```bash - # Check if required ports are available - sudo netstat -tulpn | grep -E ':(4840|502|8081)' - ``` - -### Log Files - -- Application logs: `/var/log/calejo/` -- Docker logs: `sudo docker-compose logs` -- System logs: `/var/log/syslog` - -## ๐Ÿ“ž Support - -For deployment issues: - -1. Check this deployment guide -2. Run validation script: `./validate-deployment.sh` -3. Check logs in `/var/log/calejo/` -4. Review test results from `test-e2e-deployment.py` - -## ๐ŸŽฏ Next Steps After Deployment - -1. **Validate deployment** with `./validate-deployment.sh` -2. **Run end-to-end tests** with `python test-e2e-deployment.py` -3. **Configure monitoring** in Grafana -4. **Set up backups** with cron jobs -5. **Test integration** with real SCADA/optimization systems -6. **Train users** on dashboard usage - ---- - -**Deployment Status**: โœ… Ready for Production -**Last Updated**: $(date) -**Version**: 1.0.0 \ No newline at end of file diff --git a/DEPLOYMENT_TESTING.md b/DEPLOYMENT_TESTING.md deleted file mode 100644 index b085f48..0000000 --- a/DEPLOYMENT_TESTING.md +++ /dev/null @@ -1,204 +0,0 @@ -# Deployment Testing Strategy - -This document outlines the strategy for testing deployments to ensure successful and reliable deployments to production and staging environments. - -## Current Deployment Process - -### Deployment Scripts -- **Primary Script**: `deploy/ssh/deploy-remote.sh` -- **Python Version**: `deploy/ssh/deploy-remote.py` -- **Target Server**: 95.111.206.155 (root user) -- **Configuration**: Git-ignored deployment configuration - -### Current Capabilities -- SSH-based deployment -- Environment-specific configurations (production, staging) -- Dry-run mode for testing -- Key management system -- Configuration validation - -## Deployment Testing Strategy - -### 1. Pre-Deployment Testing - -#### Local Validation -```bash -# Run all tests before deployment -./scripts/run-reliable-e2e-tests.py -pytest tests/unit/ -pytest tests/integration/ -``` - -#### Configuration Validation -```bash -# Validate deployment configuration -deploy/ssh/deploy-remote.sh -e production --dry-run --verbose -``` - -### 2. Staging Environment Testing - -#### Recommended Enhancement -Create a staging environment for pre-production testing: - -1. **Staging Server**: Separate server for testing deployments -2. **Smoke Tests**: Automated tests that verify deployment success -3. **Integration Tests**: Test with staging SCADA/optimizer services -4. **Rollback Testing**: Verify rollback procedures work - -### 3. Post-Deployment Testing - -#### Current Manual Process -After deployment, manually verify: -- Services are running -- Health endpoints respond -- Basic functionality works - -#### Recommended Automated Process -Create automated smoke tests: - -```bash -# Post-deployment smoke tests -./scripts/deployment-smoke-tests.sh -``` - -## Proposed Deployment Test Structure - -### Directory Structure -``` -tests/ -โ”œโ”€โ”€ deployment/ # Deployment-specific tests -โ”‚ โ”œโ”€โ”€ smoke_tests.py # Post-deployment smoke tests -โ”‚ โ”œโ”€โ”€ staging_tests.py # Staging environment tests -โ”‚ โ””โ”€โ”€ rollback_tests.py # Rollback procedure tests -โ””โ”€โ”€ e2e/ # Existing e2e tests (mock-dependent) -``` - -### Deployment Test Categories - -#### 1. Smoke Tests (`tests/deployment/smoke_tests.py`) -- **Purpose**: Verify basic functionality after deployment -- **Execution**: Run on deployed environment -- **Tests**: - - Service health checks - - API endpoint availability - - Database connectivity - - Basic workflow validation - -#### 2. Staging Tests (`tests/deployment/staging_tests.py`) -- **Purpose**: Full test suite on staging environment -- **Execution**: Run on staging server -- **Tests**: - - Complete e2e workflows - - Integration with staging services - - Performance validation - - Security compliance - -#### 3. Rollback Tests (`tests/deployment/rollback_tests.py`) -- **Purpose**: Verify rollback procedures work -- **Execution**: Test rollback scenarios -- **Tests**: - - Database rollback - - Configuration rollback - - Service restart procedures - -## Implementation Plan - -### Phase 1: Smoke Tests -1. Create `tests/deployment/smoke_tests.py` -2. Add basic health and connectivity tests -3. Integrate with deployment script -4. Run automatically after deployment - -### Phase 2: Staging Environment -1. Set up staging server -2. Configure staging services -3. Create staging-specific tests -4. Run full test suite on staging - -### Phase 3: Automated Deployment Pipeline -1. Integrate deployment tests with CI/CD -2. Add automated rollback triggers -3. Implement deployment metrics -4. Create deployment dashboards - -## Current Deployment Script Usage - -### Dry Run (Safe Testing) -```bash -# Test deployment without actually deploying -deploy/ssh/deploy-remote.sh -e production --dry-run --verbose -``` - -### Actual Deployment -```bash -# Deploy to production -deploy/ssh/deploy-remote.sh -e production -``` - -### With Custom Configuration -```bash -# Use custom configuration -deploy/ssh/deploy-remote.sh -e production -c deploy/config/custom.yaml -``` - -## Integration with Existing Tests - -### Mock Services vs Real Deployment -- **Mock Services**: Use for development and local testing -- **Staging Services**: Use for pre-production testing -- **Production Services**: Use for post-deployment verification - -### Test Execution Flow -``` -Local Development โ†’ Mock Services โ†’ Unit/Integration Tests - โ†“ -Staging Deployment โ†’ Staging Services โ†’ Deployment Tests - โ†“ -Production Deployment โ†’ Production Services โ†’ Smoke Tests -``` - -## Security Considerations - -### Deployment Security -- SSH key management -- Configuration encryption -- Access control -- Audit logging - -### Test Data Security -- Use test data in staging -- Never use production data in tests -- Secure test credentials -- Clean up test data - -## Monitoring and Metrics - -### Deployment Metrics -- Deployment success rate -- Rollback frequency -- Test coverage percentage -- Performance impact - -### Health Monitoring -- Service uptime -- Response times -- Error rates -- Resource utilization - -## Next Steps - -### Immediate Actions -1. Create basic smoke tests in `tests/deployment/` -2. Update deployment script to run smoke tests -3. Document deployment verification procedures - -### Medium Term -1. Set up staging environment -2. Create comprehensive deployment test suite -3. Integrate with CI/CD pipeline - -### Long Term -1. Implement automated rollback -2. Create deployment dashboards -3. Add performance benchmarking -4. Implement canary deployments \ No newline at end of file diff --git a/FINAL_TEST_SUMMARY.md b/FINAL_TEST_SUMMARY.md deleted file mode 100644 index e9d132b..0000000 --- a/FINAL_TEST_SUMMARY.md +++ /dev/null @@ -1,138 +0,0 @@ -# Calejo Control Adapter - Final Test Summary - -## ๐ŸŽ‰ TESTING COMPLETED SUCCESSFULLY ๐ŸŽ‰ - -### **Overall Status** -โœ… **125 Tests PASSED** (90% success rate) -โŒ **2 Tests FAILED** (safety framework database issues) -โŒ **12 Tests ERRORED** (legacy PostgreSQL integration tests) - ---- - -## **Detailed Test Results** - -### **Unit Tests (Core Functionality)** -โœ… **110/110 Unit Tests PASSED** (100% success rate) - -| Test Category | Tests | Passed | Coverage | -|---------------|-------|--------|----------| -| **Alert System** | 11 | 11 | 84% | -| **Auto Discovery** | 17 | 17 | 100% | -| **Configuration** | 17 | 17 | 100% | -| **Database Client** | 11 | 11 | 56% | -| **Emergency Stop** | 9 | 9 | 74% | -| **Safety Framework** | 17 | 17 | 94% | -| **Setpoint Manager** | 15 | 15 | 99% | -| **Watchdog** | 9 | 9 | 84% | -| **TOTAL** | **110** | **110** | **58%** | - -### **Integration Tests (Flexible Database Client)** -โœ… **13/13 Integration Tests PASSED** (100% success rate) - -| Test Category | Tests | Passed | Description | -|---------------|-------|--------|-------------| -| **Connection** | 2 | 2 | SQLite connection & health | -| **Data Retrieval** | 7 | 7 | Stations, pumps, plans, feedback | -| **Operations** | 2 | 2 | Queries & updates | -| **Error Handling** | 2 | 2 | Edge cases & validation | -| **TOTAL** | **13** | **13** | **100%** | - -### **Legacy Integration Tests** -โŒ **12/12 Tests ERRORED** (PostgreSQL not available) -- These tests require PostgreSQL and cannot run in this environment -- Will be replaced with flexible client tests - ---- - -## **Key Achievements** - -### **โœ… Core Functionality Verified** -- Safety framework with emergency stop -- Setpoint management with three calculator types -- Multi-protocol server interfaces -- Alert and monitoring systems -- Database watchdog and failsafe mechanisms - -### **โœ… Flexible Database Client** -- **Multi-database support** (PostgreSQL & SQLite) -- **13/13 integration tests passing** -- **Production-ready error handling** -- **Comprehensive logging and monitoring** -- **Async/await patterns implemented** - -### **โœ… Test Infrastructure** -- **110 unit tests** with comprehensive mocking -- **13 integration tests** with real SQLite database -- **Detailed test output** with coverage reports -- **Fast test execution** (under 4 seconds for all tests) - ---- - -## **Production Readiness Assessment** - -### **โœ… PASSED - Core Components** -- Safety framework implementation -- Setpoint calculation logic -- Multi-protocol server interfaces -- Alert and monitoring systems -- Error handling and fallback mechanisms - -### **โœ… PASSED - Database Layer** -- Flexible multi-database client -- SQLite integration testing -- Connection pooling and health monitoring -- Comprehensive error handling - -### **โš ๏ธ REQUIRES ATTENTION** -- **2 safety tests failing** due to database connection issues -- **Legacy integration tests** need migration to flexible client - ---- - -## **Next Steps** - -### **Immediate Actions** -1. **Migrate existing components** to use flexible database client -2. **Fix 2 failing safety tests** by updating database access -3. **Replace legacy integration tests** with flexible client versions - -### **Future Enhancements** -1. **Increase test coverage** for database client (currently 56%) -2. **Add PostgreSQL integration tests** for production validation -3. **Implement performance testing** with real workloads - ---- - -## **Conclusion** - -**โœ… Calejo Control Adapter Phase 3 is TESTED AND READY for production deployment** - -- **110 unit tests passing** with comprehensive coverage -- **13 integration tests passing** with flexible database client -- **All safety-critical components** thoroughly tested -- **Production-ready error handling** and fallback mechanisms -- **Multi-protocol interfaces** implemented and tested - -**Status**: ๐ŸŸข **PRODUCTION READY** (with minor test improvements needed) - ---- - -## **Test Environment Details** - -### **Environment** -- **Python**: 3.12.11 -- **Database**: SQLite (for integration tests) -- **Test Framework**: pytest 7.4.3 -- **Coverage**: pytest-cov 4.1.0 - -### **Test Execution** -- **Total Tests**: 139 -- **Passed**: 125 (90%) -- **Duration**: ~4 seconds -- **Coverage Reports**: Generated in `htmlcov_*` directories - -### **Flexible Database Client** -- **Status**: โœ… **IMPLEMENTED AND TESTED** -- **Databases Supported**: PostgreSQL, SQLite -- **Integration Tests**: 13/13 passing -- **Ready for Production**: โœ… **YES** \ No newline at end of file diff --git a/FLEXIBLE_DATABASE_CLIENT_SUMMARY.md b/FLEXIBLE_DATABASE_CLIENT_SUMMARY.md deleted file mode 100644 index f876e6b..0000000 --- a/FLEXIBLE_DATABASE_CLIENT_SUMMARY.md +++ /dev/null @@ -1,120 +0,0 @@ -# Flexible Database Client Implementation Summary - -## ๐ŸŽ‰ SUCCESS: Flexible Database Client Implemented and Tested! ๐ŸŽ‰ - -### **Key Achievement** -โœ… **Successfully implemented a flexible database client** that supports both PostgreSQL and SQLite using SQLAlchemy Core - ---- - -## **Test Results Summary** - -### **Overall Status** -- โœ… **125 tests PASSED** (out of 139 total tests) -- โŒ **2 tests FAILED** (safety tests with database connection issues) -- โŒ **12 tests ERRORED** (legacy integration tests still using PostgreSQL) - -### **Flexible Client Integration Tests** -โœ… **13/13 tests PASSED** - All flexible client integration tests are working perfectly! - -| Test | Status | Description | -|------|--------|-------------| -| `test_connect_sqlite` | โœ… PASSED | SQLite connection and health check | -| `test_get_pump_stations` | โœ… PASSED | Get all pump stations | -| `test_get_pumps` | โœ… PASSED | Get pumps with/without station filter | -| `test_get_pump` | โœ… PASSED | Get specific pump details | -| `test_get_current_plan` | โœ… PASSED | Get current active plan | -| `test_get_latest_feedback` | โœ… PASSED | Get latest pump feedback | -| `test_get_pump_feedback` | โœ… PASSED | Get recent feedback history | -| `test_execute_query` | โœ… PASSED | Custom query execution | -| `test_execute_update` | โœ… PASSED | Update operations | -| `test_health_check` | โœ… PASSED | Database health monitoring | -| `test_connection_stats` | โœ… PASSED | Connection statistics | -| `test_error_handling` | โœ… PASSED | Error handling and edge cases | -| `test_create_tables_idempotent` | โœ… PASSED | Table creation idempotency | - ---- - -## **Flexible Database Client Features** - -### **โœ… Multi-Database Support** -- **PostgreSQL**: `postgresql://user:pass@host:port/dbname` -- **SQLite**: `sqlite:///path/to/database.db` - -### **โœ… SQLAlchemy Core Benefits** -- **Database Abstraction**: Same code works with different databases -- **Performance**: No ORM overhead, direct SQL execution -- **Flexibility**: Easy to switch between databases -- **Testing**: SQLite for fast, reliable integration tests - -### **โœ… Key Features** -- Connection pooling (PostgreSQL) -- Automatic table creation -- Comprehensive error handling -- Structured logging -- Health monitoring -- Async support - ---- - -## **Code Quality** - -### **โœ… Architecture** -- Clean separation of concerns -- Type hints throughout -- Comprehensive error handling -- Structured logging with correlation IDs - -### **โœ… Testing** -- 13 integration tests with real SQLite database -- Comprehensive test coverage -- Proper async/await patterns -- Clean test fixtures - ---- - -## **Migration Path** - -### **Current State** -- โœ… **Flexible client implemented and tested** -- โŒ **Legacy components still use PostgreSQL client** -- โŒ **Some integration tests need updating** - -### **Next Steps** -1. **Update existing components** to use flexible client -2. **Replace PostgreSQL-specific integration tests** -3. **Update safety framework tests** to use flexible client -4. **Remove old PostgreSQL-only client** - ---- - -## **Benefits of Flexible Database Client** - -### **Development** -- โœ… **Faster testing** with SQLite -- โœ… **No PostgreSQL dependency** for development -- โœ… **Consistent API** across databases - -### **Deployment** -- โœ… **Flexible deployment options** -- โœ… **Easy environment switching** -- โœ… **Reduced infrastructure requirements** - -### **Testing** -- โœ… **Reliable integration tests** without external dependencies -- โœ… **Faster test execution** -- โœ… **Consistent test environment** - ---- - -## **Conclusion** - -**โœ… Flexible Database Client is READY for production use** - -- **13/13 integration tests passing** -- **Multi-database support implemented** -- **Comprehensive error handling** -- **Production-ready logging and monitoring** -- **Easy migration path for existing components** - -**Status**: ๐ŸŸข **PRODUCTION READY** (pending migration of existing components) \ No newline at end of file diff --git a/IMPLEMENTATION_PLAN.md b/IMPLEMENTATION_PLAN.md deleted file mode 100644 index df4635b..0000000 --- a/IMPLEMENTATION_PLAN.md +++ /dev/null @@ -1,616 +0,0 @@ -Can you make the test script output an automated result list per test file and/or system tested rathar than just a total number? Is this doable in idiomatic python?# Calejo Control Adapter - Implementation Plan - -## Overview - -This document outlines the comprehensive step-by-step implementation plan for the Calejo Control Adapter v2.0 with Safety & Security Framework. The plan is organized into 7 phases with detailed tasks, testing strategies, and acceptance criteria. - -## Recent Updates (2025-10-28) - -โœ… **Phase 1 Missing Features Completed**: All identified gaps in Phase 1 have been implemented: -- Read-only user 'control_reader' with appropriate permissions -- True async/await support for database operations -- Query timeout management -- Connection health monitoring - -โœ… **All 230 tests passing** - Comprehensive test coverage maintained across all components - -## Current Status Summary - -| Phase | Status | Completion Date | Tests Passing | -|-------|--------|-----------------|---------------| -| Phase 1: Core Infrastructure | โœ… **COMPLETE** | 2025-10-28 | All tests passing (missing features implemented) | -| Phase 2: Multi-Protocol Servers | โœ… **COMPLETE** | 2025-10-26 | All tests passing | -| Phase 3: Setpoint Management | โœ… **COMPLETE** | 2025-10-26 | All tests passing | -| Phase 4: Security Layer | โœ… **COMPLETE** | 2025-10-27 | 56/56 security tests | -| Phase 5: Protocol Servers | โœ… **COMPLETE** | 2025-10-28 | 230/230 tests passing, main app integration fixed | -| Phase 6: Integration & Testing | โณ **IN PROGRESS** | 234/234 | - | -| Phase 7: Production Hardening | โณ **PENDING** | - | - | - -**Overall Test Status:** 234/234 tests passing across all implemented components - -## Recent Updates (2025-10-28) - -### Phase 6 Integration & System Testing COMPLETED โœ… - -**Key Achievements:** -- **4 new end-to-end workflow tests** created and passing -- **Complete system validation** with 234/234 tests passing -- **Database operations workflow** tested and validated -- **Auto-discovery workflow** tested and validated -- **Optimization workflow** tested and validated -- **Database health monitoring** tested and validated - -**Test Coverage:** -- Database operations: Basic CRUD operations with test data -- Auto-discovery: Station and pump discovery workflows -- Optimization: Plan retrieval and validation workflows -- Health monitoring: Connection health and statistics - -**System Integration:** -- All components work together seamlessly -- Data flows correctly through the entire system -- Error handling and recovery tested -- Performance meets requirements - -## Project Timeline & Phases - -### Phase 1: Core Infrastructure & Database Setup (Week 1-2) โœ… **COMPLETE** - -**Objective**: Establish the foundation with database schema, core infrastructure, and basic components. - -**Phase 1 Summary**: โœ… **Core infrastructure fully functional** - All missing features implemented including async operations, query timeout management, connection health monitoring, and read-only user permissions. All critical functionality implemented and tested. - -#### TASK-1.1: Set up PostgreSQL database with complete schema -- **Description**: Create all database tables as specified in the specification -- **Database Tables**: - - `pump_stations` - Station metadata - - `pumps` - Pump configuration and control parameters - - `pump_plans` - Optimization plans from Calejo Optimize - - `pump_feedback` - Real-time feedback from pumps - - `pump_safety_limits` - Hard operational limits - - `safety_limit_violations` - Audit trail of limit violations - - `failsafe_events` - Failsafe mode activations - - `emergency_stop_events` - Emergency stop events - - `audit_log` - Immutable compliance audit trail -- **Acceptance Criteria**: โœ… **FULLY MET** - - โœ… All tables created with correct constraints and indexes - - โœ… Read-only user `control_reader` with appropriate permissions - **IMPLEMENTED** - - โœ… Test data inserted for validation - - โœ… Database connection successful from application - -#### TASK-1.2: Implement database client with connection pooling -- **Description**: Enhance database client with async support and robust error handling -- **Features**: - - โœ… Connection pooling for performance - - โœ… Async/await support for non-blocking operations - **TRUE ASYNC OPERATIONS IMPLEMENTED** - - โœ… Comprehensive error handling and retry logic - - โœ… Query timeout management - **IMPLEMENTED** - - โœ… Connection health monitoring - **IMPLEMENTED** -- **Acceptance Criteria**: โœ… **FULLY MET** - - โœ… Database operations complete within 100ms - **VERIFIED WITH PERFORMANCE TESTING** - - โœ… Connection failures handled gracefully - - โœ… Connection pool recovers automatically - - โœ… All queries execute without blocking - -#### TASK-1.3: Complete auto-discovery module -- **Description**: Implement full auto-discovery of stations and pumps from database -- **Features**: - - Automatic discovery on startup - - Periodic refresh of discovered assets - - Filtering by station and active status - - Integration with configuration -- **Acceptance Criteria**: - - All active stations and pumps discovered on startup - - Discovery completes within 30 seconds - - Configuration changes trigger rediscovery - - Invalid stations/pumps handled gracefully - -#### TASK-1.4: Implement configuration management -- **Description**: Complete settings.py with comprehensive environment variable support -- **Configuration Areas**: - - Database connection parameters - - Protocol endpoints and ports - - Safety timeout settings - - Security settings (JWT, TLS) - - Alert configuration (email, SMS, webhook) - - Logging configuration -- **Acceptance Criteria**: - - All settings loaded from environment variables - - Type validation for all configuration values - - Sensitive values properly secured - - Configuration errors provide clear messages - -#### TASK-1.5: Set up structured logging and audit system -- **Description**: Implement structlog with JSON formatting and audit trail -- **Features**: - - Structured logging in JSON format - - Correlation IDs for request tracing - - Audit trail for compliance requirements - - Log levels configurable at runtime - - Log rotation and retention policies -- **Acceptance Criteria**: - - All log entries include correlation IDs - - Audit events logged to database - - Logs searchable and filterable - - Performance impact < 5% on operations - -### Phase 2: Safety Framework Implementation (Week 3-4) โœ… **COMPLETE** - -**Objective**: Implement comprehensive safety mechanisms to prevent equipment damage and operational hazards. - -**Phase 2 Summary**: โœ… **Safety framework fully implemented** - All safety components functional with comprehensive testing coverage. - -#### TASK-2.1: Complete SafetyLimitEnforcer with all limit types -- **Description**: Implement multi-layer safety limits enforcement -- **Limit Types**: - - Speed limits (hard min/max) - - Level limits (min/max, emergency stop, dry run protection) - - Power and flow limits - - Rate of change limits - - Operational limits (starts per hour, run times) -- **Acceptance Criteria**: - - All setpoints pass through safety enforcer - - Violations logged and reported - - Rate of change limits prevent sudden changes - - Emergency stop levels trigger immediate action - -#### TASK-2.2: Implement DatabaseWatchdog with failsafe mode -- **Description**: Monitor database updates and trigger failsafe when updates stop -- **Features**: - - 20-minute timeout detection - - Automatic revert to default setpoints - - Alert generation on failsafe activation - - Automatic recovery when updates resume -- **Acceptance Criteria**: - - Failsafe triggered within 20 minutes of no updates - - Default setpoints applied correctly - - Alerts sent to operators - - System recovers automatically when updates resume - -#### TASK-2.3: Implement EmergencyStopManager with big red button -- **Description**: System-wide and targeted emergency stop functionality -- **Features**: - - Single pump emergency stop - - Station-wide emergency stop - - System-wide emergency stop - - Manual clearance with audit trail - - Integration with all protocol interfaces -- **Acceptance Criteria**: - - Emergency stop triggers within 1 second - - All affected pumps set to default setpoints - - Clear audit trail of stop/clear events - - REST API endpoints functional - -#### TASK-2.4: Implement AlertManager with multi-channel alerts -- **Description**: Email, SMS, webhook, and SCADA alarm integration -- **Alert Channels**: - - Email alerts with configurable recipients - - SMS alerts for critical events - - Webhook integration for external systems - - SCADA HMI alarm integration via OPC UA -- **Acceptance Criteria**: - - Alerts delivered within 30 seconds - - Multiple delivery attempts for failed alerts - - Alert content includes all relevant context - - Alert history maintained - -#### TASK-2.5: Create comprehensive safety tests -- **Description**: Test all safety scenarios including edge cases and failure modes -- **Test Scenarios**: - - Normal operation within limits - - Safety limit violations - - Failsafe mode activation and recovery - - Emergency stop functionality - - Alert delivery verification -- **Acceptance Criteria**: - - 100% test coverage for safety components - - All failure modes tested and handled - - Performance under load validated - - Integration with other components verified - -### Phase 3: Plan-to-Setpoint Logic Engine (Week 5-6) โœ… **COMPLETE** - -**Objective**: Implement control logic for different pump types with safety integration. - -**Phase 3 Summary**: โœ… **Setpoint management fully implemented** - All control calculators functional with safety integration and comprehensive testing. - -#### TASK-3.1: Implement SetpointManager with safety integration -- **Description**: Coordinate safety checks and setpoint calculation -- **Integration Points**: - - Emergency stop status checking - - Failsafe mode detection - - Safety limit enforcement - - Control type-specific calculation -- **Acceptance Criteria**: - - Safety checks performed before setpoint calculation - - Emergency stop overrides all other logic - - Failsafe mode uses default setpoints - - Performance: setpoint calculation < 10ms - -#### TASK-3.2: Create control calculators for different pump types -- **Description**: Implement calculators for DIRECT_SPEED, LEVEL_CONTROLLED, POWER_CONTROLLED -- **Calculator Types**: - - DirectSpeedCalculator: Direct speed control - - LevelControlledCalculator: Level-based control with PID - - PowerControlledCalculator: Power-based optimization -- **Acceptance Criteria**: - - Each calculator produces valid setpoints - - Control parameters configurable per pump - - Feedback integration for adaptive control - - Smooth transitions between setpoints - -#### TASK-3.3: Implement feedback integration -- **Description**: Use real-time feedback for adaptive control -- **Feedback Sources**: - - Actual speed measurements - - Power consumption - - Flow rates - - Wet well levels - - Pump running status -- **Acceptance Criteria**: - - Feedback used to validate setpoint effectiveness - - Adaptive control based on actual performance - - Feedback delays handled appropriately - - Invalid feedback data rejected - -#### TASK-3.4: Create plan-to-setpoint integration tests -- **Description**: Test all control scenarios with safety integration -- **Test Scenarios**: - - Normal optimization plan execution - - Control type-specific calculations - - Safety limit integration - - Emergency stop override - - Failsafe mode operation -- **Acceptance Criteria**: - - All control scenarios tested - - Safety integration verified - - Performance requirements met - - Edge cases handled correctly - -### Phase 4: Security Layer Implementation (Week 4-5) โœ… **COMPLETE** - -**Objective**: Implement comprehensive security features including authentication, authorization, TLS/SSL encryption, and compliance audit logging. - -#### TASK-4.1: Implement authentication and authorization โœ… **COMPLETE** -- **Description**: JWT-based authentication with bcrypt password hashing and role-based access control -- **Security Features**: - - JWT token authentication with bcrypt password hashing - - Role-based access control with 4 roles (admin, operator, engineer, viewer) - - Permission-based access control for all operations - - User management with password policies - - Token-based authentication for REST API -- **Acceptance Criteria**: โœ… **MET** - - All access properly authenticated - - Authorization rules enforced - - Session security maintained - - Security events monitored and alerted - - **24 comprehensive tests passing** - -#### TASK-4.2: Implement TLS/SSL encryption โœ… **COMPLETE** -- **Description**: Secure communications with certificate management and validation -- **Encryption Implementation**: - - TLS/SSL manager with certificate validation - - Certificate rotation monitoring - - Self-signed certificate generation for development - - REST API TLS support - - Secure cipher suites configuration -- **Acceptance Criteria**: โœ… **MET** - - All external communications encrypted - - Certificates properly validated - - Encryption performance acceptable - - Certificate expiration monitored - - **17 comprehensive tests passing** - -#### TASK-4.3: Implement compliance audit logging โœ… **COMPLETE** -- **Description**: Enhanced audit logging compliant with IEC 62443, ISO 27001, and NIS2 -- **Audit Requirements**: - - Comprehensive audit event types (35+ event types) - - Audit trail retrieval and query capabilities - - Compliance reporting generation - - Immutable log storage - - Integration with all security events -- **Acceptance Criteria**: โœ… **MET** - - Audit trail complete and searchable - - Logs protected from tampering - - Compliance reports generatable - - Retention policies enforced - - **15 comprehensive tests passing** - -#### TASK-4.4: Create security compliance documentation โœ… **COMPLETE** -- **Description**: Document compliance with standards and security controls -- **Documentation Areas**: - - Security architecture documentation - - Compliance matrix for standards - - Security control implementation details - - Risk assessment documentation - - Incident response procedures -- **Acceptance Criteria**: โœ… **MET** - - Documentation complete and accurate - - Compliance evidence documented - - Security controls mapped to requirements - - Documentation maintained and versioned - -**Phase 4 Summary**: โœ… **56 security tests passing** - All requirements exceeded with more secure implementations than originally specified - -### Phase 5: Protocol Server Enhancement (Week 5-6) โœ… **COMPLETE** - -**Objective**: Enhance protocol servers with security integration and complete multi-protocol support. - -#### TASK-5.1: Enhance OPC UA Server with security integration -- **Description**: Integrate security layer with OPC UA server -- **Security Integration**: - - Certificate-based authentication for OPC UA - - Role-based authorization for OPC UA operations - - Security event logging for OPC UA access - - Integration with compliance audit logging - - Secure communication with OPC UA clients -- **Acceptance Criteria**: - - OPC UA clients authenticated and authorized - - Security events logged to audit trail - - Performance: < 100ms response time - - Error conditions handled gracefully - -#### TASK-5.2: Enhance Modbus TCP Server with security features -- **Description**: Add security controls to Modbus TCP server -- **Security Features**: - - IP-based access control for Modbus - - Rate limiting for Modbus requests - - Security event logging for Modbus operations - - Integration with compliance audit logging - - Secure communication validation -- **Acceptance Criteria**: - - Unauthorized Modbus access blocked - - Security events logged to audit trail - - Performance: < 50ms response time - - Error responses for invalid requests - -#### TASK-5.3: Complete REST API security integration -- **Description**: Finalize REST API security with all endpoints protected -- **API Security**: - - All REST endpoints protected with JWT authentication - - Role-based authorization for all operations - - Rate limiting and request validation - - Security headers and CORS configuration - - OpenAPI documentation with security schemes -- **Acceptance Criteria**: - - All endpoints properly secured - - Authentication required for sensitive operations - - Performance: < 200ms response time - - OpenAPI documentation complete - -#### TASK-5.4: Create protocol security integration tests -- **Description**: Test security integration across all protocol interfaces -- **Test Scenarios**: - - OPC UA client authentication and authorization - - Modbus TCP access control and rate limiting - - REST API endpoint security testing - - Cross-protocol security consistency - - Performance under security overhead -- **Acceptance Criteria**: โœ… **MET** - - All protocols properly secured - - Security controls effective across interfaces - - Performance requirements met under security overhead - - Error conditions handled gracefully - -**Phase 5 Summary**: โœ… **220 total tests passing** - All protocol servers enhanced with security integration, performance optimizations, and comprehensive monitoring. Implementation exceeds requirements with additional performance features and production readiness. **Main application integration issue resolved**. - -### Phase 6: Integration & System Testing (Week 10-11) โณ **IN PROGRESS** - -**Objective**: End-to-end testing and validation of the complete system. - -#### TASK-6.1: Set up test database with realistic data โณ **IN PROGRESS** -- **Description**: Create test data for multiple stations and pump scenarios -- **Test Data**: - - Multiple pump stations with different configurations - - Various pump types and control strategies - - Historical optimization plans - - Safety limit configurations - - Realistic feedback data -- **Acceptance Criteria**: - - Test data covers all scenarios - - Data relationships maintained - - Performance testing possible - - Edge cases represented -- **Current Status**: Basic test data exists but needs expansion for full scenarios - -#### TASK-6.2: Create end-to-end integration tests โณ **IN PROGRESS** -- **Description**: Test full system workflow from optimization to SCADA -- **Test Workflows**: - - Normal optimization control flow - - Safety limit violation handling - - Emergency stop activation and clearance - - Failsafe mode operation - - Protocol integration testing -- **Acceptance Criteria**: - - All workflows function correctly - - Data flows through entire system - - Performance meets requirements - - Error conditions handled appropriately -- **Current Status**: Basic workflow tests exist but missing optimization-to-SCADA integration - -#### TASK-6.3: Implement performance and load testing โณ **PENDING** -- **Description**: Test system under load with multiple pumps and protocols -- **Load Testing**: - - Concurrent protocol connections - - High-frequency setpoint updates - - Multiple safety limit checks - - Database query performance - - Memory and CPU utilization -- **Acceptance Criteria**: - - System handles expected load - - Response times within requirements - - Resource utilization acceptable - - No memory leaks or performance degradation -- **Current Status**: Not implemented - -#### TASK-6.4: Create failure mode and recovery tests โณ **PENDING** -- **Description**: Test system behavior during failures and recovery -- **Failure Scenarios**: - - Database connection loss - - Network connectivity issues - - Protocol server failures - - Safety system failures - - Emergency stop scenarios - - Resource exhaustion -- **Recovery Testing**: - - Automatic failover procedures - - System restart and recovery - - Data consistency after recovery - - Manual intervention procedures -- **Acceptance Criteria**: - - System handles failures gracefully - - Recovery procedures work correctly - - No data loss during failures - - Manual override capabilities functional - - System fails safely - - Recovery automatic where possible - - Alerts generated for failures - - Data integrity maintained -- **Current Status**: Not implemented - -#### TASK-6.5: Implement health monitoring and metrics โณ **PENDING** -- **Description**: Prometheus metrics and health checks -- **Monitoring Areas**: - - System health and availability - - Performance metrics - - Safety system status - - Protocol connectivity - - Resource utilization -- **Acceptance Criteria**: - - All critical metrics monitored - - Health checks functional - - Alert thresholds configured - - Dashboard available for visualization - -### Phase 7: Deployment & Production Readiness (Week 12) - -**Objective**: Prepare for production deployment with operational support. - -#### TASK-7.1: Complete Docker containerization -- **Description**: Optimize Dockerfile and create docker-compose for production -- **Containerization**: - - Multi-stage Docker build - - Security scanning and vulnerability assessment - - Resource limits and constraints - - Health check implementation - - Logging configuration -- **Acceptance Criteria**: - - Container builds successfully - - Security vulnerabilities addressed - - Resource usage optimized - - Logging functional in container - -#### TASK-7.2: Create deployment documentation -- **Description**: Deployment guides, configuration examples, and troubleshooting -- **Documentation**: - - Installation and setup guide - - Configuration reference - - Troubleshooting guide - - Upgrade procedures - - Backup and recovery procedures -- **Acceptance Criteria**: - - Documentation complete and accurate - - Step-by-step procedures validated - - Common issues documented - - Maintenance procedures clear - -#### TASK-7.3: Implement monitoring and alerting -- **Description**: Grafana dashboards, alert rules, and operational monitoring -- **Monitoring Setup**: - - Grafana dashboards for all metrics - - Alert rules for critical conditions - - Log aggregation and analysis - - Performance trending - - Capacity planning data -- **Acceptance Criteria**: - - Dashboards provide operational visibility - - Alerts generated for critical conditions - - Logs searchable and analyzable - - Performance baselines established - -#### TASK-7.4: Create backup and recovery procedures -- **Description**: Database backup, configuration backup, and disaster recovery -- **Backup Strategy**: - - Database backup procedures - - Configuration backup - - Certificate and key backup - - Recovery procedures - - Testing of backup restoration -- **Acceptance Criteria**: - - Backup procedures documented and tested - - Recovery time objectives met - - Data integrity maintained - - Backup success monitored - -#### TASK-7.5: Final security review and hardening -- **Description**: Security audit, vulnerability assessment, and hardening -- **Security Activities**: - - Penetration testing - - Vulnerability scanning - - Security configuration review - - Access control validation - - Security incident response testing -- **Acceptance Criteria**: - - All security vulnerabilities addressed - - Security controls validated - - Incident response procedures tested - - Production security posture established - -## Testing Strategy - -### Unit Testing -- **Coverage**: 90%+ code coverage for all components -- **Focus**: Individual component functionality -- **Tools**: pytest, pytest-asyncio, pytest-cov - -### Integration Testing -- **Coverage**: All component interactions -- **Focus**: Data flow between components -- **Tools**: pytest with test database - -### System Testing -- **Coverage**: End-to-end workflows -- **Focus**: Complete system functionality -- **Tools**: Docker Compose, test automation - -### Performance Testing -- **Coverage**: Load and stress testing -- **Focus**: Response times and resource usage -- **Tools**: Locust, k6, custom load generators - -### Security Testing -- **Coverage**: All security controls -- **Focus**: Vulnerability assessment -- **Tools**: OWASP ZAP, security scanners - -## Risk Management - -### Technical Risks -- Database performance under load -- Protocol compatibility with SCADA systems -- Safety system reliability -- Security vulnerabilities - -### Mitigation Strategies -- Performance testing early and often -- Protocol testing with real SCADA systems -- Redundant safety mechanisms -- Regular security assessments - -## Success Criteria - -### Functional Requirements -- All safety mechanisms operational -- Multi-protocol support functional -- Real-time performance requirements met -- Compliance with standards achieved - -### Non-Functional Requirements -- 99.9% system availability -- Sub-second response times -- Secure operation validated -- Comprehensive documentation - -## Conclusion - -This implementation plan provides a comprehensive roadmap for developing the Calejo Control Adapter v2.0 with Safety & Security Framework. The phased approach ensures systematic development with thorough testing at each stage, resulting in a robust, secure, and reliable system for municipal wastewater pump station control. \ No newline at end of file diff --git a/PHASE5_ACTUAL_VERIFICATION.md b/PHASE5_ACTUAL_VERIFICATION.md deleted file mode 100644 index b8bcde7..0000000 --- a/PHASE5_ACTUAL_VERIFICATION.md +++ /dev/null @@ -1,150 +0,0 @@ -# Phase 5: Protocol Server Enhancement - Actual Requirements Verification - -## Actual Phase 5 Requirements from IMPLEMENTATION_PLAN.md - -### TASK-5.1: Enhance OPC UA Server with security integration - -#### โœ… Requirements Met: -- **Certificate-based authentication for OPC UA**: โœ… Implemented in OPC UA server initialization with TLS support -- **Role-based authorization for OPC UA operations**: โœ… Integrated with SecurityManager for RBAC -- **Security event logging for OPC UA access**: โœ… All OPC UA operations logged through ComplianceAuditLogger -- **Integration with compliance audit logging**: โœ… Full integration with audit system -- **Secure communication with OPC UA clients**: โœ… TLS support implemented - -#### โœ… Acceptance Criteria Met: -- **OPC UA clients authenticated and authorized**: โœ… SecurityManager integration provides authentication -- **Security events logged to audit trail**: โœ… All security events logged -- **Performance: < 100ms response time**: โœ… Caching ensures performance targets -- **Error conditions handled gracefully**: โœ… Comprehensive error handling - -### TASK-5.2: Enhance Modbus TCP Server with security features - -#### โœ… Requirements Met: -- **IP-based access control for Modbus**: โœ… `allowed_ips` configuration implemented -- **Rate limiting for Modbus requests**: โœ… `rate_limit_per_minute` configuration implemented -- **Security event logging for Modbus operations**: โœ… All Modbus operations logged through audit system -- **Integration with compliance audit logging**: โœ… Full integration with audit system -- **Secure communication validation**: โœ… Connection validation and security checks - -#### โœ… Additional Security Features Implemented: -- **Connection Pooling**: โœ… Prevents DoS attacks by limiting connections -- **Client Tracking**: โœ… Monitors client activity and request patterns -- **Performance Monitoring**: โœ… Tracks request success rates and failures - -#### โœ… Acceptance Criteria Met: -- **Unauthorized Modbus access blocked**: โœ… IP-based access control blocks unauthorized clients -- **Security events logged to audit trail**: โœ… All security events logged -- **Performance: < 50ms response time**: โœ… Connection pooling ensures performance -- **Error responses for invalid requests**: โœ… Comprehensive error handling - -### TASK-5.3: Complete REST API security integration - -#### โœ… Requirements Met: -- **All REST endpoints protected with JWT authentication**: โœ… HTTPBearer security implemented -- **Role-based authorization for all operations**: โœ… `require_permission` dependency factory -- **Rate limiting and request validation**: โœ… Request validation and rate limiting implemented -- **Security headers and CORS configuration**: โœ… CORS middleware with security headers -- **OpenAPI documentation with security schemes**: โœ… Enhanced OpenAPI documentation with security schemes - -#### โœ… Additional Features Implemented: -- **Response Caching**: โœ… `ResponseCache` class for performance -- **Compression**: โœ… GZip middleware for bandwidth optimization -- **Performance Monitoring**: โœ… Cache hit/miss tracking and request statistics - -#### โœ… Acceptance Criteria Met: -- **All endpoints properly secured**: โœ… All endpoints require authentication -- **Authentication required for sensitive operations**: โœ… Role-based permissions enforced -- **Performance: < 200ms response time**: โœ… Caching and compression ensure performance -- **OpenAPI documentation complete**: โœ… Comprehensive OpenAPI documentation available - -### TASK-5.4: Create protocol security integration tests - -#### โœ… Requirements Met: -- **OPC UA client authentication and authorization**: โœ… Tested in integration tests -- **Modbus TCP access control and rate limiting**: โœ… Tested in integration tests -- **REST API endpoint security testing**: โœ… Tested in integration tests -- **Cross-protocol security consistency**: โœ… All protocols use same SecurityManager -- **Performance under security overhead**: โœ… Performance monitoring tracks overhead - -#### โœ… Testing Implementation: -- **23 Unit Tests**: โœ… Comprehensive unit tests for all enhancement features -- **8 Integration Tests**: โœ… Protocol security integration tests passing -- **220 Total Tests Passing**: โœ… All tests across the system passing - -## Performance Requirements Verification - -### OPC UA Server Performance -- **Requirement**: < 100ms response time -- **Implementation**: Node caching and setpoint caching ensure sub-100ms responses -- **Verification**: Performance monitoring tracks response times - -### Modbus TCP Server Performance -- **Requirement**: < 50ms response time -- **Implementation**: Connection pooling and optimized register access -- **Verification**: Performance monitoring tracks response times - -### REST API Performance -- **Requirement**: < 200ms response time -- **Implementation**: Response caching and compression -- **Verification**: Performance monitoring tracks response times - -## Security Integration Verification - -### Cross-Protocol Security Consistency -- **Single SecurityManager**: โœ… All protocols use the same SecurityManager instance -- **Unified Audit Logging**: โœ… All security events logged through ComplianceAuditLogger -- **Consistent Authentication**: โœ… JWT tokens work across all protocols -- **Role-Based Access Control**: โœ… Same RBAC system used across all protocols - -### Compliance Requirements -- **IEC 62443**: โœ… Security controls and audit logging implemented -- **ISO 27001**: โœ… Comprehensive security management system -- **NIS2 Directive**: โœ… Critical infrastructure security requirements met - -## Additional Value-Added Features - -### Performance Monitoring -- **Unified Performance Status**: โœ… `get_protocol_performance_status()` method -- **Real-time Metrics**: โœ… Cache hit rates, connection statistics, request counts -- **Performance Logging**: โœ… Periodic performance metrics logging - -### Enhanced Configuration -- **Configurable Security**: โœ… All security features configurable -- **Performance Tuning**: โœ… Cache sizes, TTL, connection limits configurable -- **Environment-Based Settings**: โœ… Different settings for development/production - -### Production Readiness -- **Error Handling**: โœ… Comprehensive error handling and recovery -- **Resource Management**: โœ… Configurable limits prevent resource exhaustion -- **Monitoring**: โœ… Performance and security monitoring implemented - -## Verification Summary - -### โœ… All Phase 5 Requirements Fully Met -- **TASK-5.1**: OPC UA security integration โœ… COMPLETE -- **TASK-5.2**: Modbus TCP security features โœ… COMPLETE -- **TASK-5.3**: REST API security integration โœ… COMPLETE -- **TASK-5.4**: Protocol security integration tests โœ… COMPLETE - -### โœ… All Acceptance Criteria Met -- Performance requirements met across all protocols -- Security controls effective and consistent -- Comprehensive testing coverage -- Production-ready implementation - -### โœ… Additional Value Delivered -- Performance optimizations beyond requirements -- Enhanced monitoring and observability -- Production hardening features -- Comprehensive documentation - -## Conclusion - -Phase 5 has been successfully completed with all requirements fully satisfied. The implementation not only meets but exceeds the original requirements by adding: - -1. **Enhanced Performance**: Caching, pooling, and compression optimizations -2. **Comprehensive Monitoring**: Real-time performance and security monitoring -3. **Production Readiness**: Error handling, resource management, and scalability -4. **Documentation**: Complete implementation guides and configuration examples - -The protocol servers are now production-ready with industrial-grade security, performance, and reliability features. \ No newline at end of file diff --git a/PHASE5_SUMMARY.md b/PHASE5_SUMMARY.md deleted file mode 100644 index cb729a1..0000000 --- a/PHASE5_SUMMARY.md +++ /dev/null @@ -1,157 +0,0 @@ -# Phase 5: Protocol Server Enhancements - Summary - -## Overview - -Phase 5 successfully enhanced the existing protocol servers (OPC UA, Modbus TCP, REST API) with comprehensive performance optimizations, improved security features, and monitoring capabilities. These enhancements ensure the Calejo Control Adapter can handle industrial-scale workloads while maintaining security and reliability. - -## Key Achievements - -### 1. OPC UA Server Enhancements - -**Performance Optimizations:** -- โœ… **Node Caching**: Implemented `NodeCache` class with TTL and LRU eviction -- โœ… **Setpoint Caching**: In-memory caching of setpoint values with automatic invalidation -- โœ… **Enhanced Namespace Management**: Optimized node creation and organization - -**Security & Monitoring:** -- โœ… **Performance Monitoring**: Added `get_performance_status()` method -- โœ… **Enhanced Security**: Integration with SecurityManager and audit logging - -### 2. Modbus TCP Server Enhancements - -**Connection Management:** -- โœ… **Connection Pooling**: Implemented `ConnectionPool` class for efficient client management -- โœ… **Connection Limits**: Configurable maximum connections with automatic cleanup -- โœ… **Stale Connection Handling**: Automatic removal of inactive connections - -**Performance & Monitoring:** -- โœ… **Performance Tracking**: Request counting, success rate calculation -- โœ… **Enhanced Register Mapping**: Added performance metrics registers (400-499) -- โœ… **Improved Error Handling**: Better recovery from network issues - -### 3. REST API Server Enhancements - -**Documentation & Performance:** -- โœ… **OpenAPI Documentation**: Comprehensive API documentation with Swagger UI -- โœ… **Response Caching**: `ResponseCache` class with configurable TTL and size limits -- โœ… **Compression**: GZip middleware for reduced bandwidth usage - -**Security & Monitoring:** -- โœ… **Enhanced Authentication**: JWT token validation with role-based permissions -- โœ… **Performance Monitoring**: Cache hit/miss tracking and request statistics - -## Technical Implementation - -### New Classes Created - -1. **NodeCache** (`src/protocols/opcua_server.py`) - - Time-based expiration (TTL) - - Size-based eviction (LRU) - - Performance monitoring - -2. **ConnectionPool** (`src/protocols/modbus_server.py`) - - Connection limit management - - Stale connection cleanup - - Connection statistics - -3. **ResponseCache** (`src/protocols/rest_api.py`) - - Response caching with TTL - - Automatic cache eviction - - Cache statistics - -### Enhanced Configuration - -All protocol servers now support enhanced configuration options: - -- **OPC UA**: `enable_caching`, `cache_ttl_seconds`, `max_cache_size` -- **Modbus**: `enable_connection_pooling`, `max_connections` -- **REST API**: `enable_caching`, `enable_compression`, `cache_ttl_seconds` - -### Performance Monitoring Integration - -- **Main Application**: Added `get_protocol_performance_status()` method -- **Unified Monitoring**: Single interface for all protocol server performance data -- **Real-time Metrics**: Cache hit rates, connection statistics, request counts - -## Testing & Quality Assurance - -### Unit Tests -- โœ… **23 comprehensive unit tests** for all enhancement features -- โœ… **100% test coverage** for new caching and pooling classes -- โœ… **Edge case testing** for performance and security features - -### Integration Tests -- โœ… **All existing integration tests pass** (8/8) -- โœ… **No breaking changes** to existing functionality -- โœ… **Backward compatibility** maintained - -## Performance Improvements - -### Expected Performance Gains - -- **OPC UA Server**: 40-60% improvement in read operations with caching -- **Modbus TCP Server**: 30-50% better connection handling with pooling -- **REST API**: 50-70% reduction in response time with caching and compression - -### Resource Optimization - -- **Memory**: Configurable cache sizes prevent excessive memory usage -- **CPU**: Reduced computational overhead through optimized operations -- **Network**: Bandwidth savings through compression - -## Security Enhancements - -### Protocol-Specific Security -- **OPC UA**: Enhanced access control and session management -- **Modbus**: Connection pooling prevents DoS attacks -- **REST API**: Rate limiting and comprehensive authentication - -### Audit & Compliance -- All security events logged through ComplianceAuditLogger -- Performance metrics available for security monitoring -- Configurable security settings for different environments - -## Documentation - -### Comprehensive Documentation -- โœ… **Phase 5 Protocol Enhancements Guide** (`docs/phase5-protocol-enhancements.md`) -- โœ… **Configuration examples** for all enhanced features -- โœ… **Performance monitoring guide** -- โœ… **Troubleshooting and migration guide** - -## Code Quality - -### Maintainability -- **Modular Design**: Each enhancement is self-contained -- **Configurable Features**: All enhancements are opt-in -- **Clear Interfaces**: Well-documented public methods - -### Scalability -- **Horizontal Scaling**: Connection pooling enables better scaling -- **Resource Management**: Configurable limits prevent resource exhaustion -- **Performance Monitoring**: Real-time metrics for capacity planning - -## Next Steps - -### Immediate Benefits -- Improved performance for industrial-scale deployments -- Better resource utilization -- Enhanced security monitoring -- Comprehensive performance insights - -### Future Enhancement Opportunities -- Advanced caching strategies (predictive caching) -- Distributed caching for clustered deployments -- Real-time performance dashboards -- Additional industrial protocol support - -## Conclusion - -Phase 5 successfully transforms the Calejo Control Adapter from a functional implementation to a production-ready industrial control system. The protocol server enhancements provide: - -1. **Industrial-Grade Performance**: Optimized for high-throughput industrial environments -2. **Enterprise Security**: Comprehensive security features and monitoring -3. **Production Reliability**: Robust error handling and resource management -4. **Operational Visibility**: Detailed performance monitoring and metrics - -The system is now ready for deployment in demanding industrial environments with confidence in its performance, security, and reliability. \ No newline at end of file diff --git a/PHASE5_VERIFICATION.md b/PHASE5_VERIFICATION.md deleted file mode 100644 index d176739..0000000 --- a/PHASE5_VERIFICATION.md +++ /dev/null @@ -1,109 +0,0 @@ -# Phase 5: Protocol Server Enhancements - Verification Against Development Plan - -## Development Plan Requirements - -Based on the README.md, Phase 5 requirements are: - -1. **Enhanced protocol implementations** -2. **Protocol-specific optimizations** - -## Implementation Verification - -### โœ… Requirement 1: Enhanced Protocol Implementations - -#### OPC UA Server Enhancements -- **Node Caching**: โœ… Implemented `NodeCache` class with TTL and LRU eviction -- **Setpoint Caching**: โœ… In-memory caching with automatic invalidation -- **Performance Monitoring**: โœ… `get_performance_status()` method with cache metrics -- **Enhanced Security**: โœ… Integration with SecurityManager and audit logging - -#### Modbus TCP Server Enhancements -- **Connection Pooling**: โœ… Implemented `ConnectionPool` class for efficient client management -- **Performance Monitoring**: โœ… Request counting, success rate calculation, connection statistics -- **Enhanced Error Handling**: โœ… Better recovery from network issues -- **Security Integration**: โœ… Rate limiting and client tracking - -#### REST API Server Enhancements -- **Response Caching**: โœ… Implemented `ResponseCache` class with configurable TTL -- **OpenAPI Documentation**: โœ… Comprehensive API documentation with Swagger UI -- **Compression**: โœ… GZip middleware for bandwidth optimization -- **Performance Monitoring**: โœ… Cache hit/miss tracking and request statistics - -### โœ… Requirement 2: Protocol-Specific Optimizations - -#### OPC UA Optimizations -- **Namespace Management**: โœ… Optimized node creation and organization -- **Node Discovery**: โœ… Improved node lookup performance -- **Memory Management**: โœ… Configurable cache sizes and eviction policies - -#### Modbus Optimizations -- **Industrial Environment**: โœ… Connection pooling for high-concurrency industrial networks -- **Register Mapping**: โœ… Enhanced register configuration with performance metrics -- **Stale Connection Handling**: โœ… Automatic cleanup of inactive connections - -#### REST API Optimizations -- **Caching Strategy**: โœ… Time-based and size-based cache eviction -- **Rate Limiting**: โœ… Configurable request limits per client -- **Authentication Optimization**: โœ… Efficient JWT token validation - -## Additional Enhancements (Beyond Requirements) - -### Performance Monitoring Integration -- **Unified Monitoring**: โœ… `get_protocol_performance_status()` method in main application -- **Real-time Metrics**: โœ… Cache hit rates, connection statistics, request counts -- **Performance Logging**: โœ… Periodic performance metrics logging - -### Security Enhancements -- **Protocol-Specific Security**: โœ… Enhanced access control for each protocol -- **Audit Integration**: โœ… All security events logged through ComplianceAuditLogger -- **Rate Limiting**: โœ… Protection against DoS attacks - -### Testing & Quality -- **Comprehensive Testing**: โœ… 23 unit tests for enhancement features -- **Integration Testing**: โœ… All existing integration tests pass (8/8) -- **Backward Compatibility**: โœ… No breaking changes to existing functionality - -### Documentation -- **Implementation Guide**: โœ… `docs/phase5-protocol-enhancements.md` -- **Configuration Examples**: โœ… Complete configuration examples -- **Performance Monitoring Guide**: โœ… Monitoring and troubleshooting documentation - -## Performance Improvements Achieved - -### Expected Performance Gains -- **OPC UA Server**: 40-60% improvement in read operations with caching -- **Modbus TCP Server**: 30-50% better connection handling with pooling -- **REST API**: 50-70% reduction in response time with caching and compression - -### Resource Optimization -- **Memory**: Configurable cache sizes prevent excessive memory usage -- **CPU**: Reduced computational overhead through optimized operations -- **Network**: Bandwidth savings through compression - -## Verification Summary - -### โœ… All Requirements Met -1. **Enhanced protocol implementations**: โœ… Fully implemented across all three protocols -2. **Protocol-specific optimizations**: โœ… Custom optimizations for each protocol's use case - -### โœ… Additional Value Added -- **Production Readiness**: Enhanced monitoring and security features -- **Scalability**: Better resource management for industrial-scale deployments -- **Maintainability**: Modular design with clear interfaces -- **Operational Visibility**: Comprehensive performance monitoring - -### โœ… Quality Assurance -- **Test Coverage**: 31 tests passing (100% success rate) -- **Code Quality**: Modular, well-documented implementation -- **Documentation**: Comprehensive guides and examples - -## Conclusion - -Phase 5 has been successfully completed with all requirements fully satisfied and additional value-added features implemented. The protocol servers are now production-ready with: - -1. **Industrial-Grade Performance**: Optimized for high-throughput environments -2. **Enterprise Security**: Comprehensive security features and monitoring -3. **Production Reliability**: Robust error handling and resource management -4. **Operational Visibility**: Detailed performance monitoring and metrics - -The implementation exceeds the original requirements by adding comprehensive monitoring, enhanced security, and production-ready features that ensure the system can handle demanding industrial environments. \ No newline at end of file diff --git a/PHASE6_COMPLETION_SUMMARY.md b/PHASE6_COMPLETION_SUMMARY.md deleted file mode 100644 index ece42d5..0000000 --- a/PHASE6_COMPLETION_SUMMARY.md +++ /dev/null @@ -1,74 +0,0 @@ -# Phase 6 Completion Summary - -## Overview -Phase 6 (Failure Recovery and Health Monitoring) has been successfully implemented with comprehensive testing. - -## Key Achievements - -### โœ… Failure Recovery Tests (6/7 Passing) -- **Database Connection Loss Recovery** - PASSED -- **Failsafe Mode Activation** - PASSED -- **Emergency Stop Override** - PASSED (Fixed: Emergency stop correctly sets pumps to 0 Hz) -- **Safety Limit Enforcement Failure** - PASSED -- **Protocol Server Failure Recovery** - PASSED -- **Graceful Shutdown and Restart** - PASSED -- **Resource Exhaustion Handling** - XFAILED (Expected due to SQLite concurrent access limitations) - -### โœ… Performance Tests (3/3 Passing) -- **Concurrent Setpoint Updates** - PASSED -- **Concurrent Protocol Access** - PASSED -- **Memory Usage Under Load** - PASSED - -### โœ… Integration Tests (51/51 Passing) -All core integration tests are passing, demonstrating system stability and reliability. - -## Technical Fixes Implemented - -### 1. Safety Limits Loading -- Fixed missing `max_speed_change_hz_per_min` field in safety limits test data -- Added explicit call to `load_safety_limits()` in test fixtures -- Safety enforcer now properly loads and enforces all safety constraints - -### 2. Emergency Stop Logic -- Corrected test expectations: Emergency stop should set pumps to 0 Hz (not default setpoint) -- Safety enforcer correctly prioritizes emergency stop over all other logic -- Emergency stop manager properly tracks station-level and pump-level stops - -### 3. Database Connection Management -- Enhanced database connection recovery mechanisms -- Improved error handling for concurrent database access -- Fixed table creation and access patterns in test environment - -### 4. Test Data Quality -- Set `plan_status='ACTIVE'` for all pump plans in test data -- Added comprehensive safety limits for all test pumps -- Improved test fixture reliability and consistency - -## System Reliability Metrics - -### Test Coverage -- **Total Integration Tests**: 59 -- **Passing**: 56 (94.9%) -- **Expected Failures**: 1 (1.7%) -- **Port Conflicts**: 2 (3.4%) - -### Failure Recovery Capabilities -- **Database Connection Loss**: Automatic reconnection and recovery -- **Protocol Server Failures**: Graceful degradation and restart -- **Safety Limit Violations**: Immediate enforcement and logging -- **Emergency Stop**: Highest priority override (0 Hz setpoint) -- **Resource Exhaustion**: Graceful handling under extreme load - -## Health Monitoring Status -โš ๏ธ **Pending Implementation** - Prometheus metrics and health endpoints not yet implemented - -## Next Steps (Phase 7) -1. **Health Monitoring Implementation** - Add Prometheus metrics and health checks -2. **Docker Containerization** - Optimize Dockerfile for production deployment -3. **Deployment Documentation** - Create installation guides and configuration examples -4. **Monitoring and Alerting** - Implement Grafana dashboards and alert rules -5. **Backup and Recovery** - Establish database backup procedures -6. **Security Hardening** - Conduct security audit and implement hardening measures - -## Conclusion -Phase 6 has been successfully completed with robust failure recovery mechanisms implemented and thoroughly tested. The system demonstrates excellent resilience to various failure scenarios while maintaining safety as the highest priority. \ No newline at end of file diff --git a/PHASE7_COMPLETION.md b/PHASE7_COMPLETION.md deleted file mode 100644 index fee8f4d..0000000 --- a/PHASE7_COMPLETION.md +++ /dev/null @@ -1,176 +0,0 @@ -# Phase 7: Production Deployment - COMPLETED โœ… - -## Overview - -Phase 7 of the Calejo Control Adapter project has been successfully completed. This phase focused on production deployment readiness with comprehensive monitoring, security, and operational capabilities. - -## โœ… Completed Tasks - -### 1. Health Monitoring System -- **Implemented Prometheus metrics collection** -- **Added health endpoints**: `/health`, `/metrics`, `/api/v1/health/detailed` -- **Real-time monitoring** of database connections, API requests, safety violations -- **Component health checks** for all major system components - -### 2. Docker Optimization -- **Multi-stage Docker builds** for optimized production images -- **Non-root user execution** for enhanced security -- **Health checks** integrated into container orchestration -- **Environment-based configuration** for flexible deployment - -### 3. Deployment Documentation -- **Comprehensive deployment guide** (`DEPLOYMENT.md`) -- **Quick start guide** (`QUICKSTART.md`) for rapid setup -- **Configuration examples** and best practices -- **Troubleshooting guides** and common issues - -### 4. Monitoring & Alerting -- **Prometheus configuration** with custom metrics -- **Grafana dashboards** for visualization -- **Alert rules** for critical system events -- **Performance monitoring** and capacity planning - -### 5. Backup & Recovery -- **Automated backup scripts** with retention policies -- **Database and configuration backup** procedures -- **Restore scripts** for disaster recovery -- **Backup verification** and integrity checks - -### 6. Security Hardening -- **Security audit scripts** for compliance checking -- **Security hardening guide** (`SECURITY.md`) -- **Network security** recommendations -- **Container security** best practices - -## ๐Ÿš€ Production-Ready Features - -### Monitoring & Observability -- **Application metrics**: Uptime, connections, performance -- **Business metrics**: Safety violations, optimization runs -- **Infrastructure metrics**: Resource usage, database performance -- **Health monitoring**: Component status, connectivity checks - -### Security Features -- **Non-root container execution** -- **Environment-based secrets management** -- **Network segmentation** recommendations -- **Access control** and authentication -- **Security auditing** capabilities - -### Operational Excellence -- **Automated backups** with retention policies -- **Health checks** and self-healing capabilities -- **Log aggregation** and monitoring -- **Performance optimization** guidance -- **Disaster recovery** procedures - -## ๐Ÿ“Š System Architecture - -``` -โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” -โ”‚ Application โ”‚ โ”‚ Monitoring โ”‚ โ”‚ Database โ”‚ -โ”‚ โ”‚ โ”‚ โ”‚ โ”‚ โ”‚ -โ”‚ โ€ข REST API โ”‚โ—„โ”€โ”€โ–บโ”‚ โ€ข Prometheus โ”‚โ—„โ”€โ”€โ–บโ”‚ โ€ข PostgreSQL โ”‚ -โ”‚ โ€ข OPC UA Server โ”‚ โ”‚ โ€ข Grafana โ”‚ โ”‚ โ€ข Backup/Restoreโ”‚ -โ”‚ โ€ข Modbus Server โ”‚ โ”‚ โ€ข Alerting โ”‚ โ”‚ โ€ข Security โ”‚ -โ”‚ โ€ข Health Monitorโ”‚ โ”‚ โ€ข Dashboards โ”‚ โ”‚ โ”‚ -โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ -``` - -## ๐Ÿ”ง Deployment Options - -### Option 1: Docker Compose (Recommended) -```bash -# Quick start -git clone -cd calejo-control-adapter -docker-compose up -d - -# Access interfaces -# API: http://localhost:8080 -# Grafana: http://localhost:3000 -# Prometheus: http://localhost:9091 -``` - -### Option 2: Manual Installation -- Python 3.11+ environment -- PostgreSQL database -- Manual configuration -- Systemd service management - -## ๐Ÿ“ˆ Key Metrics Being Monitored - -- **Application Health**: Uptime, response times, error rates -- **Database Performance**: Connection count, query performance -- **Protocol Connectivity**: OPC UA and Modbus connections -- **Safety Systems**: Violations, emergency stops -- **Optimization**: Run frequency, duration, success rates -- **Resource Usage**: CPU, memory, disk, network - -## ๐Ÿ”’ Security Posture - -- **Container Security**: Non-root execution, minimal base images -- **Network Security**: Firewall recommendations, port restrictions -- **Data Security**: Encryption recommendations, access controls -- **Application Security**: Input validation, authentication, audit logging -- **Compliance**: Security audit capabilities, documentation - -## ๐Ÿ› ๏ธ Operational Tools - -### Backup Management -```bash -# Automated backup -./scripts/backup.sh - -# Restore from backup -./scripts/restore.sh BACKUP_ID - -# List available backups -./scripts/restore.sh --list -``` - -### Security Auditing -```bash -# Run security audit -./scripts/security_audit.sh - -# Generate detailed report -./scripts/security_audit.sh > security_report.txt -``` - -### Health Monitoring -```bash -# Check application health -curl http://localhost:8080/health - -# Detailed health status -curl http://localhost:8080/api/v1/health/detailed - -# Prometheus metrics -curl http://localhost:8080/metrics -``` - -## ๐ŸŽฏ Next Steps - -While Phase 7 is complete, consider these enhancements for future iterations: - -1. **Advanced Monitoring**: Custom dashboards for specific use cases -2. **High Availability**: Multi-node deployment with load balancing -3. **Advanced Security**: Certificate-based authentication, advanced encryption -4. **Integration**: Additional protocol support, third-party integrations -5. **Scalability**: Horizontal scaling capabilities, performance optimization - -## ๐Ÿ“ž Support & Maintenance - -- **Documentation**: Comprehensive guides in `/docs` directory -- **Monitoring**: Real-time dashboards and alerting -- **Backup**: Automated backup procedures -- **Security**: Regular audit capabilities -- **Updates**: Version management and upgrade procedures - ---- - -**Phase 7 Status**: โœ… **COMPLETED** -**Production Readiness**: โœ… **READY FOR DEPLOYMENT** -**Test Coverage**: 58/59 tests passing (98.3% success rate) -**Security**: Comprehensive hardening and audit capabilities \ No newline at end of file diff --git a/PHASE_2_COMPLETION_SUMMARY.md b/PHASE_2_COMPLETION_SUMMARY.md deleted file mode 100644 index cedd69b..0000000 --- a/PHASE_2_COMPLETION_SUMMARY.md +++ /dev/null @@ -1,101 +0,0 @@ -# Phase 2: Safety Framework Implementation - COMPLETED - -## Overview -Phase 2 of the Calejo Control Adapter has been successfully completed. The safety framework is now fully implemented with comprehensive multi-layer protection for municipal wastewater pump stations. - -## Components Implemented - -### 1. DatabaseWatchdog -- **Purpose**: Monitors database updates and triggers failsafe mode when optimization plans become stale -- **Features**: - - 20-minute timeout detection (configurable) - - Real-time monitoring of optimization plan updates - - Automatic failsafe activation when updates stop - - Failsafe recovery when updates resume - - Comprehensive status reporting - -### 2. EmergencyStopManager -- **Purpose**: Provides system-wide and targeted emergency stop functionality -- **Features**: - - Single pump emergency stop - - Station-wide emergency stop - - System-wide emergency stop - - Manual clearance with audit trail - - Integration with all protocol interfaces - - Priority-based stop hierarchy (system > station > pump) - -### 3. AlertManager -- **Purpose**: Manages multi-channel alert delivery for safety events -- **Features**: - - Email alerts with configurable recipients - - SMS alerts for critical events only - - Webhook integration for external systems - - SCADA HMI alarm integration via OPC UA - - Alert history management with size limits - - Comprehensive alert statistics - -### 4. Enhanced SafetyLimitEnforcer -- **Purpose**: Extended to integrate with emergency stop system -- **Features**: - - Emergency stop checking as highest priority - - Multi-layer safety architecture (physical, station, optimization) - - Speed limits enforcement (hard min/max, rate of change) - - Level and power limits support - - Safety limit violation logging and audit trail - -## Safety Architecture - -### Three-Layer Protection -1. **Layer 1**: Physical Hard Limits (PLC/VFD) - 15-55 Hz -2. **Layer 2**: Station Safety Limits (Database) - 20-50 Hz (enforced by SafetyLimitEnforcer) -3. **Layer 3**: Optimization Constraints (Calejo Optimize) - 25-45 Hz - -### Emergency Stop Hierarchy -- **Highest Priority**: Emergency stop (overrides all other controls) -- **Medium Priority**: Failsafe mode (stale optimization plans) -- **Standard Priority**: Safety limit enforcement - -## Testing Status -- **Total Unit Tests**: 95 -- **Passing Tests**: 95 (100% success rate) -- **Safety Framework Tests**: 29 comprehensive tests -- **Test Coverage**: All safety components thoroughly tested - -## Key Safety Features - -### Failsafe Mode -- Automatically activated when optimization system stops updating plans -- Reverts to default safe setpoints to prevent pumps from running on stale plans -- Monitors database updates every minute -- 20-minute timeout threshold (configurable) - -### Emergency Stop System -- Manual emergency stop activation via all protocol interfaces -- Three levels of stop: pump, station, system -- Audit trail for all stop and clearance events -- Manual clearance required after emergency stop - -### Multi-Channel Alerting -- Email alerts for all safety events -- SMS alerts for critical events only -- Webhook integration for external monitoring systems -- SCADA alarm integration for HMI display -- Comprehensive alert history and statistics - -## Integration Points -- **SafetyLimitEnforcer**: Now checks emergency stop status before enforcing limits -- **Main Application**: All safety components integrated and initialized -- **Protocol Servers**: Emergency stop functionality available via all interfaces -- **Database**: Safety events and audit trails recorded - -## Configuration -All safety components are fully configurable via the settings system: -- Timeout thresholds -- Alert recipients and channels -- Safety limit values -- Emergency stop behavior - -## Next Steps -Phase 2 is complete and ready for production deployment. The safety framework provides comprehensive protection for pump station operations with multiple layers of redundancy and failsafe mechanisms. - -**Status**: โœ… **COMPLETED AND READY FOR PRODUCTION** \ No newline at end of file diff --git a/PHASE_3_COMPLETION_SUMMARY.md b/PHASE_3_COMPLETION_SUMMARY.md deleted file mode 100644 index f5aca21..0000000 --- a/PHASE_3_COMPLETION_SUMMARY.md +++ /dev/null @@ -1,163 +0,0 @@ -# Phase 3 Completion Summary: Setpoint Manager & Protocol Servers - -## โœ… **PHASE 3 COMPLETED** - -### **Overview** -Phase 3 successfully implements the core control logic and multi-protocol interface layer of the Calejo Control Adapter. This phase completes the end-to-end control loop from optimization plans to SCADA system integration. - -### **Components Implemented** - -#### 1. **SetpointManager** (`src/core/setpoint_manager.py`) -- **Purpose**: Core component that calculates setpoints from optimization plans -- **Safety Integration**: Integrates with all safety framework components -- **Key Features**: - - Safety priority hierarchy (Emergency stop > Failsafe > Normal) - - Three calculator types for different control strategies - - Real-time setpoint calculation with safety enforcement - - Graceful degradation and fallback mechanisms - -#### 2. **Setpoint Calculators** -- **DirectSpeedCalculator**: Direct speed control using suggested_speed_hz -- **LevelControlledCalculator**: Level-based control with PID-like feedback -- **PowerControlledCalculator**: Power-based control with proportional feedback - -#### 3. **Multi-Protocol Servers** -- **REST API Server** (`src/protocols/rest_api.py`): - - FastAPI-based REST interface - - Emergency stop endpoints - - Setpoint access and status monitoring - - Authentication and authorization - -- **OPC UA Server** (`src/protocols/opcua_server.py`): - - Asyncua-based OPC UA interface - - Real-time setpoint updates - - Structured object model for stations and pumps - - Background update loop (5-second intervals) - -- **Modbus TCP Server** (`src/protocols/modbus_server.py`): - - Pymodbus-based Modbus TCP interface - - Register mapping for setpoints and status - - Binary coils for emergency stop status - - Background update loop (5-second intervals) - -#### 4. **Main Application Integration** (`src/main_phase3.py`) -- Complete application with all Phase 3 components -- Graceful startup and shutdown -- Signal handling for clean termination -- Periodic status logging - -### **Technical Architecture** - -#### **Control Flow** -``` -Calejo Optimize โ†’ Database โ†’ SetpointManager โ†’ Protocol Servers โ†’ SCADA Systems - โ†“ โ†“ โ†“ - Safety Framework Calculators Multi-Protocol -``` - -#### **Safety Priority Hierarchy** -1. **Emergency Stop** (Highest Priority) - - Immediate override of all control - - Revert to default safe setpoints - -2. **Failsafe Mode** - - Triggered by database watchdog - - Conservative operation mode - - Revert to default setpoints - -3. **Normal Operation** - - Setpoint calculation from optimization plans - - Safety limit enforcement - - Real-time feedback integration - -### **Testing Results** - -#### **Unit Tests** -- **Total Tests**: 110 unit tests -- **Phase 3 Tests**: 15 new tests for SetpointManager and calculators -- **Success Rate**: 100% passing -- **Coverage**: All new components thoroughly tested - -#### **Test Categories** -1. **Setpoint Calculators** (5 tests) - - Direct speed calculation - - Level-controlled with feedback - - Power-controlled with feedback - - Fallback mechanisms - -2. **SetpointManager** (10 tests) - - Normal operation - - Emergency stop scenarios - - Failsafe mode scenarios - - Error handling - - Database integration - -### **Key Features Implemented** - -#### **Safety Integration** -- โœ… Emergency stop override -- โœ… Failsafe mode activation -- โœ… Safety limit enforcement -- โœ… Multi-layer protection - -#### **Protocol Support** -- โœ… REST API with authentication -- โœ… OPC UA server with structured data -- โœ… Modbus TCP with register mapping -- โœ… Simultaneous multi-protocol operation - -#### **Real-Time Operation** -- โœ… Background update loops -- โœ… 5-second update intervals -- โœ… Graceful error handling -- โœ… Performance optimization - -#### **Production Readiness** -- โœ… Comprehensive error handling -- โœ… Graceful degradation -- โœ… Logging and monitoring -- โœ… Configuration management - -### **Files Created/Modified** - -#### **New Files** -- `src/core/setpoint_manager.py` - Core setpoint management -- `src/protocols/rest_api.py` - REST API server -- `src/protocols/opcua_server.py` - OPC UA server -- `src/protocols/modbus_server.py` - Modbus TCP server -- `src/main_phase3.py` - Complete Phase 3 application -- `tests/unit/test_setpoint_manager.py` - Unit tests - -#### **Modified Files** -- `src/database/client.py` - Added missing database methods - -### **Next Steps (Phase 4)** - -#### **Security Layer Implementation** -- Authentication and authorization -- API key management -- Role-based access control -- Audit logging - -#### **Production Deployment** -- Docker containerization -- Kubernetes deployment -- Monitoring and alerting -- Performance optimization - -### **Status** - -**โœ… PHASE 3 COMPLETED SUCCESSFULLY** - -- All components implemented and tested -- 110 unit tests passing (100% success rate) -- Code committed and pushed to repository -- Ready for Phase 4 development - ---- - -**Repository**: `calejocontrol/CalejoControl` -**Branch**: `phase2-safety-framework-completion` -**Pull Request**: #1 (Phase 2 & 3 combined) -**Test Status**: โœ… **110/110 tests passing** -**Production Ready**: โœ… **YES** \ No newline at end of file diff --git a/POSTGRESQL_ANALYSIS.md b/POSTGRESQL_ANALYSIS.md deleted file mode 100644 index 133aaf1..0000000 --- a/POSTGRESQL_ANALYSIS.md +++ /dev/null @@ -1,82 +0,0 @@ -# PostgreSQL Analysis: Would It Resolve the Remaining Test Failure? - -## Executive Summary - -**โœ… YES, PostgreSQL would resolve the remaining test failure.** - -The single remaining test failure (`test_resource_exhaustion_handling`) is caused by SQLite's limitations with concurrent database access, which PostgreSQL is specifically designed to handle. - -## Current Test Status - -- **Integration Tests**: 58/59 passing (98.3% success rate) -- **Performance Tests**: All passing -- **Failure Recovery Tests**: 6/7 passing, 1 xfailed - -## The Problem: SQLite Concurrent Access Limitations - -### Failing Test: `test_resource_exhaustion_handling` -- **Location**: `tests/integration/test_failure_recovery.py` -- **Issue**: Concurrent database queries fail with SQLite in-memory database -- **Error**: `sqlite3.OperationalError: no such table: pump_plans` - -### Root Cause Analysis -1. **SQLite In-Memory Database**: Each thread connection creates a separate database instance -2. **Table Visibility**: Tables created in one connection are not visible to other connections -3. **Concurrent Access**: Multiple threads trying to access the same in-memory database fail - -## Experimental Verification - -We conducted a controlled experiment comparing: - -### Test 1: In-Memory SQLite (Current Failing Case) -- **Database URL**: `sqlite:///:memory:` -- **Results**: 0 successful, 10 failed (100% failure rate) -- **Errors**: `no such table` and database closure errors - -### Test 2: File-Based SQLite (Better Concurrency) -- **Database URL**: `sqlite:///temp_file.db` -- **Results**: 10 successful, 0 failed (100% success rate) -- **Conclusion**: File-based SQLite handles concurrent access much better - -## PostgreSQL Advantage - -### Why PostgreSQL Would Solve This -1. **Client-Server Architecture**: Single database server handles all connections -2. **Connection Pooling**: Sophisticated connection management -3. **Concurrent Access**: Designed for high-concurrency scenarios -4. **Production-Ready**: Enterprise-grade database for mission-critical applications - -### PostgreSQL Configuration -- **Default Port**: 5432 -- **Connection String**: `postgresql://user:pass@host:port/dbname` -- **Already Configured**: System supports PostgreSQL as default database - -## System Readiness Assessment - -### โœ… Production Ready -- **Core Functionality**: All critical features working -- **Safety Systems**: Emergency stop, safety limits, watchdog all functional -- **Protocol Support**: OPC UA, Modbus, REST API all tested -- **Performance**: Load tests passing with dynamic port allocation - -### โš ๏ธ Known Limitations (Resolved by PostgreSQL) -- **Test Environment**: SQLite in-memory database limitations -- **Production Environment**: PostgreSQL handles concurrent access perfectly - -## Recommendations - -### Immediate Actions -1. **Keep xfail Marker**: Maintain `@pytest.mark.xfail` for the resource exhaustion test -2. **Document Limitation**: Clearly document this as a SQLite test environment limitation -3. **Production Deployment**: Use PostgreSQL as configured - -### Long-term Strategy -1. **Production Database**: PostgreSQL for all production deployments -2. **Test Environment**: Consider using file-based SQLite for better test reliability -3. **Monitoring**: Implement PostgreSQL performance monitoring in production - -## Conclusion - -The Calejo Control Adapter system is **production-ready** with 98.3% test coverage. The single remaining test failure is a **known limitation of the test environment** (SQLite in-memory database) and would be **completely resolved by using PostgreSQL in production**. - -**Next Steps**: Proceed with Phase 7 deployment tasks as the core system is stable and reliable. \ No newline at end of file diff --git a/PROJECT_COMPLETION.md b/PROJECT_COMPLETION.md deleted file mode 100644 index 2e33628..0000000 --- a/PROJECT_COMPLETION.md +++ /dev/null @@ -1,261 +0,0 @@ -# Calejo Control Adapter - PROJECT COMPLETED โœ… - -## ๐ŸŽ‰ Project Overview - -We have successfully completed the Calejo Control Adapter project with comprehensive features for industrial control systems, including safety frameworks, multiple protocol support, monitoring, and an interactive dashboard. - -## โœ… Major Accomplishments - -### Phase 1-6: Core System Development -- **Safety Framework**: Emergency stop system with failsafe mechanisms -- **Protocol Support**: OPC UA and Modbus integration -- **Setpoint Management**: Real-time control with optimization -- **Security System**: JWT authentication and role-based access -- **Database Integration**: PostgreSQL with comprehensive schema -- **Testing Framework**: 58/59 tests passing (98.3% success rate) - -### Interactive Dashboard -- **Web Interface**: Modern, responsive dashboard with tab-based navigation -- **Configuration Management**: Web-based configuration editor with validation -- **Real-time Monitoring**: Live system status and log viewing -- **System Actions**: One-click operations (restart, backup, health checks) -- **Comprehensive Testing**: 35/35 dashboard tests passing (100% success rate) - -### Phase 7: Production Deployment -- **Health Monitoring**: Prometheus metrics and health checks -- **Docker Optimization**: Multi-stage builds and container orchestration -- **Monitoring Stack**: Prometheus, Grafana, and alerting -- **Backup & Recovery**: Automated backup scripts with retention -- **Security Hardening**: Security audit scripts and hardening guide - -### Interactive Dashboard -- **Web Interface**: Modern, responsive dashboard -- **Configuration Management**: Web-based configuration editor -- **Real-time Monitoring**: Live system status and logs -- **System Actions**: One-click operations and health checks -- **Mobile Support**: Responsive design for all devices - -## ๐Ÿš€ Key Features - -### Safety & Control -- **Emergency Stop System**: Multi-level safety with audit logging -- **Failsafe Mechanisms**: Automatic fallback to safe states -- **Setpoint Optimization**: Real-time optimization algorithms -- **Safety Violation Detection**: Comprehensive monitoring and alerts - -### Protocol Support -- **OPC UA Server**: Industrial standard protocol with security -- **Modbus TCP Server**: Legacy system compatibility -- **REST API**: Modern web API with OpenAPI documentation -- **Protocol Discovery**: Automatic device discovery and mapping - -### Monitoring & Observability -- **Health Monitoring**: Component-level health checks -- **Prometheus Metrics**: Comprehensive system metrics -- **Grafana Dashboards**: Advanced visualization and alerting -- **Performance Tracking**: Request caching and optimization - -### Security -- **JWT Authentication**: Secure token-based authentication -- **Role-Based Access**: Granular permission system -- **Input Validation**: Comprehensive data validation -- **Security Auditing**: Regular security checks and monitoring - -### Deployment & Operations -- **Docker Containerization**: Production-ready containers -- **Docker Compose**: Full stack deployment -- **Backup Procedures**: Automated backup and restore -- **Security Hardening**: Production security guidelines - -### Interactive Dashboard -- **Web Interface**: Accessible at `http://localhost:8080/dashboard` -- **Configuration Management**: All system settings via web UI -- **Real-time Status**: Live system monitoring -- **System Logs**: Centralized log viewing -- **One-click Actions**: Backup, restart, health checks - -## ๐Ÿ“Š System Architecture - -``` -โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ” -โ”‚ Application โ”‚ โ”‚ Monitoring โ”‚ โ”‚ Database โ”‚ -โ”‚ โ”‚ โ”‚ โ”‚ โ”‚ โ”‚ -โ”‚ โ€ข REST API โ”‚โ—„โ”€โ”€โ–บโ”‚ โ€ข Prometheus โ”‚โ—„โ”€โ”€โ–บโ”‚ โ€ข PostgreSQL โ”‚ -โ”‚ โ€ข OPC UA Server โ”‚ โ”‚ โ€ข Grafana โ”‚ โ”‚ โ€ข Backup/Restoreโ”‚ -โ”‚ โ€ข Modbus Server โ”‚ โ”‚ โ€ข Alerting โ”‚ โ”‚ โ€ข Security โ”‚ -โ”‚ โ€ข Health Monitorโ”‚ โ”‚ โ€ข Dashboards โ”‚ โ”‚ โ”‚ -โ”‚ โ€ข Dashboard โ”‚ โ”‚ โ”‚ โ”‚ โ”‚ -โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ -``` - -## ๐Ÿ”ง Deployment Options - -### Option 1: Docker Compose (Recommended) -```bash -# Quick start -git clone -cd calejo-control-adapter -docker-compose up -d - -# Access interfaces -# Dashboard: http://localhost:8080/dashboard -# API: http://localhost:8080 -# Grafana: http://localhost:3000 -# Prometheus: http://localhost:9091 -``` - -### Option 2: Manual Installation -- Python 3.11+ environment -- PostgreSQL database -- Manual configuration -- Systemd service management - -## ๐Ÿ“ˆ Production Metrics - -### Application Health -- **Uptime Monitoring**: Real-time system availability -- **Performance Metrics**: Response times and throughput -- **Error Tracking**: Comprehensive error logging -- **Resource Usage**: CPU, memory, and disk monitoring - -### Business Metrics -- **Safety Violations**: Emergency stop events and causes -- **Optimization Performance**: Setpoint optimization success rates -- **Protocol Connectivity**: OPC UA and Modbus connection status -- **Database Performance**: Query performance and connection health - -### Infrastructure Metrics -- **Container Health**: Docker container status and resource usage -- **Network Performance**: Latency and bandwidth monitoring -- **Storage Health**: Disk usage and backup status -- **Security Metrics**: Authentication attempts and security events - -## ๐Ÿ”’ Security Posture - -### Container Security -- **Non-root Execution**: Containers run as non-root users -- **Minimal Base Images**: Optimized for security and size -- **Health Checks**: Container-level health monitoring -- **Network Security**: Restricted port exposure - -### Application Security -- **Input Validation**: Comprehensive data validation -- **Authentication**: JWT token-based authentication -- **Authorization**: Role-based access control -- **Audit Logging**: Comprehensive security event logging - -### Network Security -- **Firewall Recommendations**: Network segmentation guidelines -- **TLS/SSL Support**: Encrypted communication -- **Access Controls**: Network-level access restrictions -- **Monitoring**: Network security event monitoring - -## ๐Ÿ› ๏ธ Operational Tools - -### Backup Management -```bash -# Automated backup -./scripts/backup.sh - -# Restore from backup -./scripts/restore.sh BACKUP_ID - -# List available backups -./scripts/restore.sh --list -``` - -### Security Auditing -```bash -# Run security audit -./scripts/security_audit.sh - -# Generate detailed report -./scripts/security_audit.sh > security_report.txt -``` - -### Health Monitoring -```bash -# Check application health -curl http://localhost:8080/health - -# Detailed health status -curl http://localhost:8080/api/v1/health/detailed - -# Prometheus metrics -curl http://localhost:8080/metrics -``` - -### Dashboard Access -``` -http://localhost:8080/dashboard -``` - -## ๐Ÿ“š Documentation - -### Comprehensive Guides -- **DEPLOYMENT.md**: Complete deployment instructions -- **QUICKSTART.md**: Quick start guide for new users -- **SECURITY.md**: Security hardening guidelines -- **DASHBOARD.md**: Dashboard user guide -- **API Documentation**: OpenAPI/Swagger documentation - -### Technical Documentation -- **Architecture Overview**: System design and components -- **Configuration Guide**: All configuration options -- **Troubleshooting Guide**: Common issues and solutions -- **Security Guide**: Security best practices - -## ๐ŸŽฏ Next Steps - -While the project is complete and production-ready, consider these enhancements for future iterations: - -### Advanced Features -1. **High Availability**: Multi-node deployment with load balancing -2. **Advanced Analytics**: Machine learning for optimization -3. **Mobile App**: Native mobile application -4. **Integration APIs**: Third-party system integration - -### Performance Optimization -1. **Horizontal Scaling**: Support for multiple instances -2. **Caching Layers**: Advanced caching strategies -3. **Database Optimization**: Query optimization and indexing -4. **Protocol Enhancements**: Additional industrial protocols - -### Security Enhancements -1. **Advanced Authentication**: Multi-factor authentication -2. **Certificate Management**: Automated certificate rotation -3. **Security Monitoring**: Advanced threat detection -4. **Compliance**: Industry-specific compliance features - -## ๐Ÿ“ž Support & Maintenance - -### Documentation -- **User Guides**: Comprehensive user documentation -- **API Reference**: Complete API documentation -- **Troubleshooting**: Common issues and solutions -- **Best Practices**: Operational best practices - -### Monitoring -- **Health Checks**: Automated health monitoring -- **Alerting**: Proactive alerting for issues -- **Performance Monitoring**: Continuous performance tracking -- **Security Monitoring**: Security event monitoring - -### Maintenance -- **Regular Updates**: Security and feature updates -- **Backup Verification**: Regular backup testing -- **Security Audits**: Regular security assessments -- **Performance Optimization**: Continuous performance improvements - ---- - -## ๐ŸŽ‰ PROJECT STATUS: COMPLETED โœ… - -**Production Readiness**: โœ… **READY FOR DEPLOYMENT** -**Test Coverage**: 58/59 tests passing (98.3% success rate) -**Security**: Comprehensive security framework -**Monitoring**: Complete observability stack -**Documentation**: Comprehensive documentation -**Dashboard**: Interactive web interface - -**Congratulations! The Calejo Control Adapter is now a complete, production-ready industrial control system with comprehensive safety features, multiple protocol support, advanced monitoring, and an intuitive web dashboard.** \ No newline at end of file diff --git a/QUICK_START.md b/QUICK_START.md deleted file mode 100644 index 73aa905..0000000 --- a/QUICK_START.md +++ /dev/null @@ -1,141 +0,0 @@ -# Calejo Control Adapter - Quick Start Guide - -## ๐Ÿš€ One-Click Setup - -### Automatic Configuration Detection - -The setup script automatically reads from existing deployment configuration files in the `deploy/` directory: - -```bash -# Make the setup script executable -chmod +x setup-server.sh - -# Run the one-click setup (auto-detects from deploy/config/production.yml) -./setup-server.sh -``` - -### For Local Development - -```bash -# Override to local deployment -./setup-server.sh -h localhost -``` - -### For Staging Environment - -```bash -# Use staging configuration -./setup-server.sh -e staging -``` - -### Dry Run (See what will be done) - -```bash -# Preview the setup process -./setup-server.sh --dry-run -``` - -## ๐Ÿ“‹ What the Setup Script Does - -### 1. **Prerequisites Check** -- โœ… Verifies Docker and Docker Compose are installed -- โœ… Checks disk space and system resources -- โœ… Validates network connectivity - -### 2. **Automatic Configuration** -- โœ… **Reads existing deployment config** from `deploy/config/production.yml` -- โœ… **Uses SSH settings** from existing deployment scripts -- โœ… Creates necessary directories and sets permissions -- โœ… Generates secure JWT secrets automatically -- โœ… Sets up SSL certificates for production -- โœ… Configures safe default settings - -### 3. **Application Deployment** -- โœ… Builds and starts all Docker containers -- โœ… Waits for services to become healthy -- โœ… Validates all components are working -- โœ… Starts the dashboard automatically - -### 4. **Ready to Use** -- โœ… Dashboard available at `http://localhost:8080/dashboard` -- โœ… REST API available at `http://localhost:8080` -- โœ… Health monitoring at `http://localhost:8080/health` - -## ๐ŸŽฏ Next Steps After Setup - -### 1. **Access the Dashboard** -Open your browser and navigate to: -``` -http://your-server:8080/dashboard -``` - -### 2. **Initial Configuration** -Use the dashboard to: -- **Configure SCADA Protocols**: Set up OPC UA, Modbus TCP connections -- **Define Pump Stations**: Add your pump stations and equipment -- **Set Safety Limits**: Configure operational boundaries -- **Create Users**: Set up operator and administrator accounts - -### 3. **Integration** -- Connect your existing SCADA systems -- Configure data points and setpoints -- Test emergency stop functionality -- Set up monitoring and alerts - -## ๐Ÿ”ง Manual Setup (Alternative) - -If you prefer manual setup: - -```bash -# Clone the repository -git clone -cd calejo-control-adapter - -# Copy configuration -cp config/.env.example .env - -# Edit configuration (optional) -nano .env - -# Start services -docker-compose up -d - -# Verify setup -curl http://localhost:8080/health -``` - -## ๐Ÿ” Default Credentials - -After deployment, use these credentials to access the services: - -### Grafana Dashboard -- **URL**: http://localhost:3000 (or your server IP:3000) -- **Username**: admin -- **Password**: admin - -### Prometheus Metrics -- **URL**: http://localhost:9091 (or your server IP:9091) -- **Authentication**: None required by default - -### PostgreSQL Database -- **Host**: localhost:5432 -- **Database**: calejo -- **Username**: calejo -- **Password**: password - -### Main Application -- **Dashboard**: http://localhost:8080/dashboard -- **API**: http://localhost:8080 -- **Authentication**: JWT-based (configure users through dashboard) - -**Security Note**: Change the default Grafana admin password after first login! - -## ๐Ÿ“ž Support - -- **Documentation**: Check the `docs/` directory for comprehensive guides -- **Issues**: Report problems via GitHub issues -- **Community**: Join our community forum for help - ---- - -*Your Calejo Control Adapter should now be running and ready for configuration through the web dashboard!* \ No newline at end of file diff --git a/REMOTE_DASHBOARD_DEPLOYMENT_SUMMARY.md b/REMOTE_DASHBOARD_DEPLOYMENT_SUMMARY.md deleted file mode 100644 index 7eeacf0..0000000 --- a/REMOTE_DASHBOARD_DEPLOYMENT_SUMMARY.md +++ /dev/null @@ -1,77 +0,0 @@ -# Remote Dashboard Deployment Summary - -## Overview -Successfully deployed the Calejo Control Adapter dashboard to the remote server at `95.111.206.155` on port 8081. - -## Deployment Status - -### โœ… SUCCESSFULLY DEPLOYED -- **Remote Dashboard**: Running on `http://95.111.206.155:8081` -- **Health Check**: Accessible at `/health` endpoint -- **Service Status**: Healthy and running -- **SSH Access**: Working correctly - -### ๐Ÿ”„ CURRENT SETUP -- **Existing Production**: Port 8080 (original Calejo Control Adapter) -- **Test Deployment**: Port 8081 (new dashboard deployment) -- **Mock Services**: - - Mock SCADA: `http://95.111.206.155:8083` - - Mock Optimizer: `http://95.111.206.155:8084` - -## Key Achievements - -1. **SSH Deployment**: Successfully deployed via SSH to remote server -2. **Container Configuration**: Fixed Docker command to use `python -m src.main` -3. **Port Configuration**: Test deployment running on port 8081 (mapped to container port 8080) -4. **Health Monitoring**: Health check endpoint working correctly - -## Deployment Details - -### Remote Server Information -- **Host**: `95.111.206.155` -- **SSH User**: `root` -- **SSH Key**: `deploy/keys/production_key` -- **Deployment Directory**: `/opt/calejo-control-adapter-test` - -### Service Configuration -- **Container Name**: `calejo-control-adapter-test-app-1` -- **Port Mapping**: `8081:8080` -- **Health Check**: `curl -f http://localhost:8080/health` -- **Command**: `python -m src.main` - -## Access URLs - -- **Dashboard**: http://95.111.206.155:8081 -- **Health Check**: http://95.111.206.155:8081/health -- **Existing Production**: http://95.111.206.155:8080 - -## Verification - -All deployment checks passed: -- โœ… SSH connection established -- โœ… Docker container built and running -- โœ… Health endpoint accessible -- โœ… Service logs showing normal operation -- โœ… Port 8081 accessible from external - -## Next Steps - -1. **Test Discovery**: Verify the dashboard can discover remote services -2. **Protocol Mapping**: Test protocol mapping functionality -3. **Integration Testing**: Test end-to-end integration with mock services -4. **Production Deployment**: Consider deploying to production environment - -## Files Modified - -- `docker-compose.test.yml` - Fixed command and port configuration - -## Deployment Scripts Used - -- `deploy/ssh/deploy-remote.sh -e test` - Main deployment script -- Manual fixes for Docker command configuration - -## Notes - -- The deployment successfully resolved the issue where the container was trying to run `start_dashboard.py` instead of the correct `python -m src.main` -- The test deployment runs alongside the existing production instance without conflicts -- SSH deployment is now working correctly after the initial connection issues were resolved \ No newline at end of file diff --git a/REMOTE_DEPLOYMENT_SUMMARY.md b/REMOTE_DEPLOYMENT_SUMMARY.md deleted file mode 100644 index 01e23ff..0000000 --- a/REMOTE_DEPLOYMENT_SUMMARY.md +++ /dev/null @@ -1,85 +0,0 @@ -# Remote Deployment Summary - -## Overview -Successfully deployed and tested the Calejo Control Adapter with remote services. The system is configured to discover and interact with remote mock SCADA and optimizer services running on `95.111.206.155`. - -## Deployment Status - -### โœ… COMPLETED -- **Local Dashboard**: Running on `localhost:8080` -- **Remote Services**: Successfully discovered and accessible -- **Discovery Functionality**: Working correctly -- **Integration Testing**: All tests passed - -### ๐Ÿ”„ CURRENT SETUP -- **Dashboard Location**: Local (`localhost:8080`) -- **Remote Services**: - - Mock SCADA: `http://95.111.206.155:8083` - - Mock Optimizer: `http://95.111.206.155:8084` - - Existing API: `http://95.111.206.155:8080` - -## Key Achievements - -1. **Protocol Discovery**: Successfully discovered 3 endpoints: - - Mock SCADA Service (REST API) - - Mock Optimizer Service (REST API) - - Local Dashboard (REST API) - -2. **Remote Integration**: Local dashboard can discover and interact with remote services - -3. **Configuration**: Created remote test configuration (`config/test-remote.yml`) - -4. **Automated Testing**: Created integration test script (`test-remote-integration.py`) - -## Usage Instructions - -### Start Remote Test Environment -```bash -./start-remote-test.sh -``` - -### Run Integration Tests -```bash -python test-remote-integration.py -``` - -### Access Dashboard -- **URL**: http://localhost:8080 -- **Discovery API**: http://localhost:8080/api/v1/dashboard/discovery - -## API Endpoints Tested - -- `GET /health` - Dashboard health check -- `GET /api/v1/dashboard/discovery/status` - Discovery status -- `POST /api/v1/dashboard/discovery/scan` - Start discovery scan -- `GET /api/v1/dashboard/discovery/recent` - Recent discoveries - -## Technical Notes - -- SSH deployment to remote server not possible (port 22 blocked) -- Alternative approach: Local dashboard + remote service discovery -- All remote services accessible via HTTP on standard ports -- Discovery service successfully identifies REST API endpoints - -## Next Steps - -1. **Production Deployment**: Consider deploying dashboard to remote server via alternative methods -2. **Protocol Mapping**: Implement protocol mapping for discovered endpoints -3. **Security**: Add authentication and authorization -4. **Monitoring**: Set up monitoring and alerting - -## Files Created - -- `config/test-remote.yml` - Remote test configuration -- `start-remote-test.sh` - Startup script for remote testing -- `test-remote-integration.py` - Integration test script -- `REMOTE_DEPLOYMENT_SUMMARY.md` - This summary document - -## Verification - -All tests passed successfully: -- โœ… Dashboard health check -- โœ… Remote service connectivity -- โœ… Discovery scan functionality -- โœ… Endpoint discovery (3 endpoints found) -- โœ… Integration with remote services \ No newline at end of file diff --git a/SIMPLIFIED_WORKFLOW.md b/SIMPLIFIED_WORKFLOW.md deleted file mode 100644 index 25416a4..0000000 --- a/SIMPLIFIED_WORKFLOW.md +++ /dev/null @@ -1,157 +0,0 @@ -# Simplified Deployment Workflow - -## ๐ŸŽฏ User Vision Achieved - -**"Run one script to set up the server, then configure everything through the web dashboard."** - -## ๐Ÿ“‹ Complete Workflow - -### Step 1: Run the Setup Script - -```bash -./setup-server.sh -``` - -**What happens automatically:** -- โœ… **Reads existing configuration** from `deploy/config/production.yml` -- โœ… **Uses SSH settings** from `deploy/ssh/deploy-remote.sh` -- โœ… **Checks prerequisites** (Docker, dependencies) -- โœ… **Provisions server** and installs required software -- โœ… **Deploys application** with all services -- โœ… **Starts dashboard** and validates health -- โœ… **Displays access URLs** and next steps - -### Step 2: Access the Dashboard - -Open your browser to: -``` -http://your-server:8080/dashboard -``` - -### Step 3: Configure Everything Through Web Interface - -**No manual configuration files or SSH access needed!** - -#### Configuration Categories Available: - -1. **SCADA Protocols** - - OPC UA server configuration - - Modbus TCP settings - - REST API endpoints - -2. **Hardware Discovery & Management** - - Auto-discover pump stations - - Configure pump equipment - - Set communication parameters - -3. **Safety Framework** - - Define operational limits - - Configure emergency stop procedures - - Set safety boundaries - -4. **User Management** - - Create operator accounts - - Set role-based permissions - - Configure authentication - -5. **Monitoring & Alerts** - - Set up performance monitoring - - Configure alert thresholds - - Define notification methods - -## ๐Ÿ”ง Technical Implementation - -### Automatic Configuration Reading - -The setup script intelligently reads from existing deployment files: - -```bash -# Reads from deploy/config/production.yml -host: "95.111.206.155" -username: "root" -key_file: "deploy/keys/production_key" - -# Reads from deploy/ssh/deploy-remote.sh -SSH_HOST="95.111.206.155" -SSH_USER="root" -SSH_KEY="deploy/keys/production_key" -``` - -### Command-Line Override Support - -Override any auto-detected values: - -```bash -# Local development -./setup-server.sh -h localhost - -# Staging environment -./setup-server.sh -e staging - -# Custom SSH user -./setup-server.sh -u custom-user - -# Preview mode -./setup-server.sh --dry-run -``` - -## ๐Ÿ“ Repository Structure - -``` -calejo-control-adapter/ -โ”œโ”€โ”€ setup-server.sh # One-click setup script -โ”œโ”€โ”€ deploy/ # Existing deployment configuration -โ”‚ โ”œโ”€โ”€ config/ -โ”‚ โ”‚ โ”œโ”€โ”€ production.yml # Production server settings -โ”‚ โ”‚ โ””โ”€โ”€ staging.yml # Staging server settings -โ”‚ โ””โ”€โ”€ ssh/ -โ”‚ โ””โ”€โ”€ deploy-remote.sh # Remote deployment script -โ”œโ”€โ”€ src/dashboard/ -โ”‚ โ”œโ”€โ”€ configuration_manager.py # Web-based configuration system -โ”‚ โ””โ”€โ”€ api.py # Dashboard API endpoints -โ”œโ”€โ”€ docs/ -โ”‚ โ”œโ”€โ”€ DASHBOARD_CONFIGURATION_GUIDE.md # Complete web config guide -โ”‚ โ””โ”€โ”€ [11 other comprehensive guides] -โ”œโ”€โ”€ QUICK_START.md # Simplified getting started -โ””โ”€โ”€ README.md # Updated with new workflow -``` - -## ๐ŸŽ‰ Benefits Achieved - -### For Users -- **Zero manual configuration** - everything through web dashboard -- **No SSH access required** for routine operations -- **Intuitive web interface** for all configuration -- **Automatic deployment** with existing settings - -### For Administrators -- **Consistent deployments** using existing configuration -- **Easy overrides** when needed -- **Comprehensive logging** and monitoring -- **Safety-first approach** built-in - -### For Developers -- **Clear separation** between deployment and configuration -- **Extensible architecture** for new features -- **Comprehensive documentation** for all components -- **Tested and validated** implementation - -## ๐Ÿš€ Getting Started - -1. **Clone the repository** -2. **Run the setup script**: `./setup-server.sh` -3. **Access the dashboard**: `http://your-server:8080/dashboard` -4. **Configure everything** through the web interface - -**That's it! No manual configuration files, no SSH access, no complex setup procedures.** - ---- - -## ๐Ÿ“š Documentation - -- **[Quick Start Guide](QUICK_START.md)** - Getting started instructions -- **[Dashboard Configuration Guide](docs/DASHBOARD_CONFIGURATION_GUIDE.md)** - Complete web-based configuration -- **[System Architecture](docs/SYSTEM_ARCHITECTURE.md)** - Technical architecture overview -- **[Safety Framework](docs/SAFETY_FRAMEWORK.md)** - Safety and emergency procedures - -**The user's vision is now fully implemented: one script to set up the server, then configure everything through the web dashboard.** \ No newline at end of file diff --git a/TESTING_STRATEGY.md b/TESTING_STRATEGY.md deleted file mode 100644 index 2a4ebae..0000000 --- a/TESTING_STRATEGY.md +++ /dev/null @@ -1,110 +0,0 @@ -# Testing Strategy - -This document outlines the testing strategy for the Calejo Control Adapter project. - -## Test Directory Structure - -``` -tests/ -โ”œโ”€โ”€ unit/ # Unit tests - test individual components in isolation -โ”œโ”€โ”€ integration/ # Integration tests - test components working together -โ”œโ”€โ”€ e2e/ # End-to-end tests - require external services (mocks) -โ”œโ”€โ”€ fixtures/ # Test fixtures and data -โ”œโ”€โ”€ utils/ # Test utilities -โ””โ”€โ”€ mock_services/ # Mock SCADA and optimizer services -``` - -## Test Categories - -### 1. Unit Tests (`tests/unit/`) -- **Purpose**: Test individual functions, classes, and modules in isolation -- **Dependencies**: None or minimal (mocked dependencies) -- **Execution**: `pytest tests/unit/` -- **Examples**: Database clients, configuration validation, business logic - -### 2. Integration Tests (`tests/integration/`) -- **Purpose**: Test how components work together -- **Dependencies**: May require database, but not external services -- **Execution**: `pytest tests/integration/` -- **Examples**: Database integration, protocol handlers working together - -### 3. End-to-End Tests (`tests/e2e/`) -- **Purpose**: Test complete workflows with external services -- **Dependencies**: Require mock SCADA and optimizer services -- **Execution**: Use dedicated runner scripts -- **Examples**: Complete SCADA-to-optimizer workflows - -### 4. Mock Services (`tests/mock_services/`) -- **Purpose**: Simulate external SCADA and optimizer services -- **Usage**: Started by e2e test runners -- **Ports**: SCADA (8081), Optimizer (8082) - -## Test Runners - -### For E2E Tests (Mock-Dependent) -```bash -# Starts mock services and runs e2e tests -./scripts/run-reliable-e2e-tests.py - -# Quick mock service verification -./scripts/test-mock-services.sh - -# Full test environment setup -./scripts/setup-test-environment.sh -``` - -### For Unit and Integration Tests -```bash -# Run all unit tests -pytest tests/unit/ - -# Run all integration tests -pytest tests/integration/ - -# Run specific test file -pytest tests/unit/test_database_client.py -``` - -## Deployment Testing - -### Current Strategy -- **Deployment Script**: `deploy/ssh/deploy-remote.sh` -- **Purpose**: Deploy to production server (95.111.206.155) -- **Testing**: Manual verification after deployment -- **Separation**: Deployment is separate from automated testing - -### Recommended Enhancement -To add automated deployment testing: -1. Create `tests/deployment/` directory -2. Add smoke tests that verify deployment -3. Run these tests after deployment -4. Consider using staging environment for pre-production testing - -## Test Execution Guidelines - -### When to Run Which Tests -- **Local Development**: Run unit tests frequently -- **Before Commits**: Run unit + integration tests -- **Before Deployment**: Run all tests including e2e -- **CI/CD Pipeline**: Run all test categories - -### Mock Service Usage -- E2E tests require mock services to be running -- Use dedicated runners that manage service lifecycle -- Don't run e2e tests directly with pytest (they'll fail) - -## Adding New Tests - -1. **Unit Tests**: Add to `tests/unit/` -2. **Integration Tests**: Add to `tests/integration/` -3. **E2E Tests**: Add to `tests/e2e/` and update runners if needed -4. **Mock Services**: Add to `tests/mock_services/` if new services needed - -## Best Practices - -- Keep tests fast and isolated -- Use fixtures for common setup -- Mock external dependencies in unit tests -- Write descriptive test names -- Include both happy path and error scenarios -- Use retry logic for flaky network operations \ No newline at end of file diff --git a/TEST_ENVIRONMENT.md b/TEST_ENVIRONMENT.md deleted file mode 100644 index 1f56afa..0000000 --- a/TEST_ENVIRONMENT.md +++ /dev/null @@ -1,318 +0,0 @@ -# Test Environment Setup - -This document describes how to set up and use the test environment with mock SCADA and optimizer services for the Calejo Control Adapter. - -## Overview - -The test environment provides: -- **Mock SCADA System**: Simulates industrial process data with realistic variations -- **Mock Optimizer Service**: Provides optimization models for energy, production, and cost -- **Test Data Generator**: Automatically generates test scenarios and validates the system -- **Complete Docker Environment**: All services running in isolated containers - -## Quick Start - -### 1. Setup Test Environment - -```bash -# Run the setup script (this will create all necessary files and start services) -./scripts/setup-test-environment.sh -``` - -### 2. Test Mock Services - -```bash -# Quick test to verify all services are running -./scripts/test-mock-services.sh -``` - -### 3. Cleanup - -```bash -# Stop and remove test services -./scripts/setup-test-environment.sh --clean -``` - -## Services Overview - -### Mock SCADA System -- **Port**: 8081 -- **Purpose**: Simulates industrial SCADA system with process data -- **Features**: - - Real-time process data (temperature, pressure, flow rate, etc.) - - Equipment control (pumps, valves, compressors) - - Alarm generation - - Data variation simulation - -**Endpoints:** -- `GET /health` - Health check -- `GET /api/v1/data` - Get all SCADA data -- `GET /api/v1/data/{tag}` - Get specific data tag -- `POST /api/v1/control/{equipment}` - Control equipment -- `GET /api/v1/alarms` - Get current alarms - -### Mock Optimizer Service -- **Port**: 8082 -- **Purpose**: Simulates optimization algorithms for industrial processes -- **Features**: - - Energy consumption optimization - - Production efficiency optimization - - Cost reduction optimization - - Forecast generation - -**Endpoints:** -- `GET /health` - Health check -- `GET /api/v1/models` - Get available optimization models -- `POST /api/v1/optimize/{model}` - Run optimization -- `GET /api/v1/history` - Get optimization history -- `POST /api/v1/forecast` - Generate forecasts - -### Calejo Control Adapter (Test Version) -- **Port**: 8080 -- **Purpose**: Main application with test configuration -- **Features**: - - Dashboard interface - - REST API - - Integration with mock services - - Health monitoring - -## Test Scenarios - -The test environment supports multiple scenarios: - -### 1. Normal Operation -- All services running normally -- Stable process data -- No alarms - -### 2. High Load -- Simulated high production load -- Increased energy consumption -- Potential efficiency drops - -### 3. Low Efficiency -- Suboptimal process conditions -- Reduced production efficiency -- Optimization recommendations - -### 4. Alarm Conditions -- Triggered alarms (high temperature, high pressure) -- Emergency response testing -- Safety system validation - -### 5. Optimization Testing -- Energy optimization scenarios -- Production optimization -- Cost reduction strategies - -## Usage Examples - -### Testing SCADA Integration - -```bash -# Get current SCADA data -curl http://localhost:8081/api/v1/data - -# Control equipment -curl -X POST http://localhost:8081/api/v1/control/pump_1 \ - -H "Content-Type: application/json" \ - -d '{"command": "START"}' - -# Check alarms -curl http://localhost:8081/api/v1/alarms -``` - -### Testing Optimization - -```bash -# Get available optimization models -curl http://localhost:8082/api/v1/models - -# Run energy optimization -curl -X POST http://localhost:8082/api/v1/optimize/energy_optimization \ - -H "Content-Type: application/json" \ - -d '{"power_load": 450, "time_of_day": 14, "production_rate": 95}' - -# Get optimization history -curl http://localhost:8082/api/v1/history?limit=5 -``` - -### Testing Calejo API - -```bash -# Health check -curl http://localhost:8080/health - -# Dashboard access -curl http://localhost:8080/dashboard - -# API status -curl http://localhost:8080/api/v1/status -``` - -## Development Workflow - -### 1. Start Test Environment -```bash -./scripts/setup-test-environment.sh -``` - -### 2. Run Tests -```bash -# Run unit tests -python -m pytest tests/unit/ - -# Run integration tests -python -m pytest tests/integration/ - -# Run end-to-end tests (requires mock services) -./scripts/run-reliable-e2e-tests.py - -# Run comprehensive test suite -python -m pytest tests/ -``` - -### 3. Generate Test Data -```bash -# Run the test data generator -./scripts/setup-test-environment.sh -# (The script automatically runs the test data generator) - -# Or run it manually -docker-compose -f docker-compose.test.yml run --rm test-data-generator -``` - -### 4. Monitor Services -```bash -# View all logs -docker-compose -f docker-compose.test.yml logs -f - -# View specific service logs -docker-compose -f docker-compose.test.yml logs -f calejo-control-adapter-test -``` - -## Configuration - -The test environment uses `docker-compose.test.yml` which includes: - -- **calejo-control-adapter-test**: Main application with test configuration -- **calejo-postgres-test**: PostgreSQL database -- **calejo-mock-scada**: Mock SCADA system -- **calejo-mock-optimizer**: Mock optimizer service -- **calejo-test-data-generator**: Test data generator - -## Troubleshooting - -### Services Not Starting -- Check if Docker is running: `docker ps` -- Check if ports are available: `netstat -tulpn | grep 8080` -- View logs: `docker-compose -f docker-compose.test.yml logs` - -### Health Checks Failing -- Wait for services to initialize (30 seconds) -- Check individual service health: - ```bash - curl http://localhost:8080/health - curl http://localhost:8081/health - curl http://localhost:8082/health - ``` - -### Mock Services Not Responding -- Restart services: `docker-compose -f docker-compose.test.yml restart` -- Recreate containers: `docker-compose -f docker-compose.test.yml up -d --force-recreate` - -## Cleanup - -To completely remove the test environment: - -```bash -# Stop and remove containers -./scripts/setup-test-environment.sh --clean - -# Remove created files (optional) -rm docker-compose.test.yml -rm -rf tests/mock_services/ -``` - -## Automated Testing - -The test environment includes comprehensive automated tests: - -### Test Categories - -1. **Health Checks** - Verify all services are running -2. **API Tests** - Test REST API endpoints -3. **Unit Tests** - Test individual components -4. **Integration Tests** - Test service interactions -5. **End-to-End Tests** - Test complete workflows - -### Running Tests - -#### Using the Test Runner Script - -```bash -# Run all tests -./scripts/run-mock-tests.sh - -# Run specific test categories -./scripts/run-mock-tests.sh --health -./scripts/run-mock-tests.sh --api -./scripts/run-mock-tests.sh --unit -./scripts/run-mock-tests.sh --integration -./scripts/run-mock-tests.sh --e2e - -# Wait for services only -./scripts/run-mock-tests.sh --wait-only -``` - -#### Using Pytest Directly - -```bash -# Run all tests -python -m pytest tests/ - -# Run mock service integration tests -python -m pytest tests/integration/test_mock_services.py -v - -# Run with specific markers -python -m pytest tests/ -m "mock" -v -python -m pytest tests/ -m "integration" -v -``` - -### Test Coverage - -The automated tests cover: - -- **Mock SCADA Service**: Health, data retrieval, equipment control, alarms -- **Mock Optimizer Service**: Health, model listing, optimization, forecasting -- **Calejo Control Adapter**: Health, dashboard, API endpoints -- **End-to-End Workflows**: SCADA to optimization, alarm response, forecast planning - -### Test Configuration - -- **pytest-mock.ini**: Configuration for mock service tests -- **60-second timeout**: Services must be ready within 60 seconds -- **Comprehensive error handling**: Tests handle service unavailability gracefully - -## Continuous Integration - -For CI/CD pipelines, the test runner can be integrated: - -```yaml -# Example GitHub Actions workflow -- name: Run Mock Service Tests - run: | - ./scripts/setup-test-environment.sh - ./scripts/run-mock-tests.sh --all -``` - -## Next Steps - -After setting up the test environment: - -1. **Run the test suite** to validate functionality -2. **Test integration scenarios** with the mock services -3. **Develop new features** using the test environment -4. **Validate deployments** before production - -For production deployment, use the deployment scripts in the `deploy/` directory. \ No newline at end of file diff --git a/TEST_FAILURES_INVESTIGATION_SUMMARY.md b/TEST_FAILURES_INVESTIGATION_SUMMARY.md deleted file mode 100644 index 6a99f8e..0000000 --- a/TEST_FAILURES_INVESTIGATION_SUMMARY.md +++ /dev/null @@ -1,102 +0,0 @@ -# Test Failures Investigation Summary - -## Overview -All remaining test failures have been successfully resolved. The system now demonstrates excellent test stability and reliability. - -## Issues Investigated and Resolved - -### โœ… 1. Port Binding Conflicts (FIXED) -**Problem**: Tests were failing with `OSError: [Errno 98] address already in use` on ports 4840, 5020, and 8000. - -**Root Cause**: Multiple tests trying to bind to the same hardcoded ports during parallel test execution. - -**Solution Implemented**: -- Created `tests/utils/port_utils.py` with `find_free_port()` utility -- Updated failing tests to use dynamic ports: - - `test_opcua_server_setpoint_exposure` - now uses dynamic OPC UA port - - `test_concurrent_protocol_access` - now uses dynamic ports for all protocols - -**Result**: All port binding conflicts eliminated. Tests now run reliably in parallel. - -### โœ… 2. Database Compliance Audit Error (FIXED) -**Problem**: Compliance audit logging was failing with `"List argument must consist only of tuples or dictionaries"` - -**Root Cause**: The database client's `execute` method expected dictionary parameters, but the code was passing a tuple. - -**Solution Implemented**: -- Updated `src/core/compliance_audit.py` to use named parameters (`:timestamp`, `:event_type`, etc.) -- Changed parameter format from tuple to dictionary - -**Result**: Compliance audit logging now works correctly without database errors. - -### โœ… 3. Emergency Stop Logic (FIXED) -**Problem**: Emergency stop test was expecting default setpoint (35.0) instead of correct 0.0 Hz during emergency stop. - -**Root Cause**: Test expectation was incorrect - emergency stop should stop pumps (0 Hz), not use default setpoint. - -**Solution Implemented**: -- Updated test assertion from `assert emergency_setpoint == 35.0` to `assert emergency_setpoint == 0.0` - -**Result**: Emergency stop functionality correctly verified. - -### โœ… 4. Safety Limits Loading (FIXED) -**Problem**: Safety enforcer was failing due to missing `max_speed_change_hz_per_min` field. - -**Root Cause**: Test data was incomplete for safety limits. - -**Solution Implemented**: -- Added `max_speed_change_hz_per_min=10.0` to all safety limits test data -- Added explicit call to `load_safety_limits()` in test fixtures - -**Result**: Safety limits properly loaded and enforced. - -## Current Test Status - -### Integration Tests -- **Total Tests**: 59 -- **Passing**: 58 (98.3%) -- **Expected Failures**: 1 (1.7%) -- **Failures**: 0 (0%) - -### Performance Tests -- **Total Tests**: 3 -- **Passing**: 3 (100%) -- **Failures**: 0 (0%) - -### Failure Recovery Tests -- **Total Tests**: 7 -- **Passing**: 6 (85.7%) -- **Expected Failures**: 1 (14.3%) -- **Failures**: 0 (0%) - -## Expected Failure Analysis - -### Resource Exhaustion Handling Test (XFAILED) -**Reason**: SQLite has limitations with concurrent database access -**Status**: Expected failure - not a system issue -**Impact**: Low - this is a test environment limitation, not a production issue - -## System Reliability Metrics - -### Test Coverage -- **Core Functionality**: 100% passing -- **Safety Systems**: 100% passing -- **Protocol Servers**: 100% passing -- **Database Operations**: 100% passing -- **Failure Recovery**: 85.7% passing (100% of actual system failures) - -### Performance Metrics -- **Concurrent Setpoint Updates**: Passing -- **Protocol Access Performance**: Passing -- **Memory Usage Under Load**: Passing - -## Conclusion -All significant test failures have been resolved. The system demonstrates: - -1. **Robustness**: Handles various failure scenarios correctly -2. **Safety**: Emergency stop and safety limits work as expected -3. **Performance**: Meets performance requirements under load -4. **Reliability**: All core functionality tests pass -5. **Maintainability**: Dynamic port allocation prevents test conflicts - -The Calejo Control Adapter is now ready for production deployment with comprehensive test coverage and proven reliability. \ No newline at end of file diff --git a/TEST_INVESTIGATION_SUMMARY.md b/TEST_INVESTIGATION_SUMMARY.md deleted file mode 100644 index 6d95cf8..0000000 --- a/TEST_INVESTIGATION_SUMMARY.md +++ /dev/null @@ -1,151 +0,0 @@ -# Test Investigation and Fix Summary - -## ๐ŸŽ‰ SUCCESS: All Test Issues Resolved! ๐ŸŽ‰ - -### **Final Test Results** -โœ… **133 Tests PASSED** (96% success rate) -โŒ **6 Tests ERRORED** (Legacy PostgreSQL integration tests - expected) - ---- - -## **Investigation and Resolution Summary** - -### **1. Safety Framework Tests (2 FAILED โ†’ 2 PASSED)** - -**Issue**: `AttributeError: 'NoneType' object has no attribute 'execute'` - -**Root Cause**: Safety framework was trying to record violations to database even when database client was `None` (in tests). - -**Fix**: Added null check in `_record_violation()` method: -```python -if not self.db_client: - # Database client not available - skip recording - return -``` - -**Status**: โœ… **FIXED** - ---- - -### **2. SQLite Integration Tests (6 ERRORED โ†’ 6 PASSED)** - -#### **Issue 1**: Wrong database client class -- **Problem**: Tests were using old `DatabaseClient` (PostgreSQL-only) -- **Fix**: Updated to use `FlexibleDatabaseClient` - -#### **Issue 2**: Wrong method names -- **Problem**: Tests calling `initialize()` instead of `discover()` -- **Fix**: Updated method calls to match actual class methods - -#### **Issue 3**: Missing database method -- **Problem**: `FlexibleDatabaseClient` missing `get_safety_limits()` method -- **Fix**: Added method to flexible client - -#### **Issue 4**: SQL parameter format -- **Problem**: Safety framework using tuple parameters instead of dictionary -- **Fix**: Updated to use named parameters with dictionary - -#### **Issue 5**: Missing database table -- **Problem**: `safety_limit_violations` table didn't exist -- **Fix**: Added table definition to flexible client - -**Status**: โœ… **ALL FIXED** - ---- - -### **3. Legacy PostgreSQL Integration Tests (6 ERRORED)** - -**Issue**: PostgreSQL not available in test environment - -**Assessment**: These tests are **expected to fail** in this environment because: -- They require a running PostgreSQL instance -- They use the old PostgreSQL-only database client -- They are redundant now that we have SQLite integration tests - -**Recommendation**: These tests should be: -1. **Marked as skipped** when PostgreSQL is not available -2. **Eventually replaced** with flexible client versions -3. **Kept for production validation** when PostgreSQL is available - -**Status**: โœ… **EXPECTED BEHAVIOR** - ---- - -## **Key Technical Decisions** - -### **โœ… Code Changes (Production Code)** -1. **Safety Framework**: Added null check for database client -2. **Flexible Client**: Added missing `get_safety_limits()` method -3. **Flexible Client**: Added `safety_limit_violations` table definition -4. **Safety Framework**: Fixed SQL parameter format for SQLAlchemy - -### **โœ… Test Changes (Test Code)** -1. **Updated SQLite integration tests** to use flexible client -2. **Fixed method calls** to match actual class methods -3. **Updated parameter assertions** for flexible client API - -### **โœ… Architecture Improvements** -1. **Multi-database support** now fully functional -2. **SQLite integration tests** provide reliable testing without external dependencies -3. **Flexible client** can be used in both production and testing - ---- - -## **Test Coverage Analysis** - -### **โœ… Core Functionality (110/110 PASSED)** -- Safety framework with emergency stop -- Setpoint management with three calculator types -- Multi-protocol server interfaces -- Alert and monitoring systems -- Database watchdog and failsafe mechanisms - -### **โœ… Flexible Database Client (13/13 PASSED)** -- SQLite connection and health monitoring -- Data retrieval (stations, pumps, plans, feedback) -- Query execution and updates -- Error handling and edge cases - -### **โœ… Integration Tests (10/10 PASSED)** -- Component interaction with real database -- Auto-discovery with safety framework -- Error handling integration -- Database operations - -### **โŒ Legacy PostgreSQL Tests (6/6 ERRORED)** -- **Expected failure** - PostgreSQL not available -- **Redundant** - Same functionality covered by SQLite tests - ---- - -## **Production Readiness Assessment** - -### **โœ… PASSED - All Critical Components** -- **Safety framework**: Thoroughly tested with edge cases -- **Database layer**: Multi-database support implemented and tested -- **Integration**: Components work together correctly -- **Error handling**: Comprehensive error handling tested - -### **โœ… PASSED - Test Infrastructure** -- **110 unit tests**: All passing with comprehensive mocking -- **13 flexible client tests**: All passing with SQLite -- **10 integration tests**: All passing with real database -- **Fast execution**: ~4 seconds for all tests - -### **โš ๏ธ KNOWN LIMITATIONS** -- **PostgreSQL integration tests** require external database -- **Legacy database client** still exists but not used in new tests - ---- - -## **Conclusion** - -**โœ… Calejo Control Adapter is FULLY TESTED and PRODUCTION READY** - -- **133/139 tests passing** (96% success rate) -- **All safety-critical components** thoroughly tested -- **Flexible database client** implemented and tested -- **Multi-protocol interfaces** working correctly -- **Comprehensive error handling** verified - -**Status**: ๐ŸŸข **PRODUCTION READY** (with minor legacy test cleanup needed) \ No newline at end of file diff --git a/TEST_RESULTS_SUMMARY.md b/TEST_RESULTS_SUMMARY.md deleted file mode 100644 index 8eec00a..0000000 --- a/TEST_RESULTS_SUMMARY.md +++ /dev/null @@ -1,163 +0,0 @@ -# Calejo Control Adapter - Test Results Summary - -## ๐ŸŽ‰ TESTING COMPLETED SUCCESSFULLY ๐ŸŽ‰ - -### **Overall Status** -โœ… **110 Unit Tests PASSED** (100% success rate) -โš ๏ธ **Integration Tests SKIPPED** (PostgreSQL not available in test environment) - ---- - -## **Detailed Test Results** - -### **Unit Tests Breakdown** - -| Test Category | Tests | Passed | Failed | Coverage | -|---------------|-------|--------|--------|----------| -| **Alert System** | 11 | 11 | 0 | 84% | -| **Auto Discovery** | 17 | 17 | 0 | 100% | -| **Configuration** | 17 | 17 | 0 | 100% | -| **Database Client** | 11 | 11 | 0 | 56% | -| **Emergency Stop** | 9 | 9 | 0 | 74% | -| **Safety Framework** | 17 | 17 | 0 | 94% | -| **Setpoint Manager** | 15 | 15 | 0 | 99% | -| **Watchdog** | 9 | 9 | 0 | 84% | -| **TOTAL** | **110** | **110** | **0** | **58%** | - ---- - -## **Test Coverage Analysis** - -### **High Coverage Components (80%+)** -- โœ… **Auto Discovery**: 100% coverage -- โœ… **Configuration**: 100% coverage -- โœ… **Setpoint Manager**: 99% coverage -- โœ… **Safety Framework**: 94% coverage -- โœ… **Alert System**: 84% coverage -- โœ… **Watchdog**: 84% coverage - -### **Medium Coverage Components** -- โš ๏ธ **Emergency Stop**: 74% coverage -- โš ๏ธ **Database Client**: 56% coverage (mocked for unit tests) - -### **Main Applications** -- ๐Ÿ”ด **Main Applications**: 0% coverage (integration testing required) - ---- - -## **Key Test Features Verified** - -### **Safety Framework** โœ… -- Emergency stop functionality -- Safety limit enforcement -- Multi-level protection hierarchy -- Graceful degradation - -### **Setpoint Management** โœ… -- Three calculator types (Direct Speed, Level Controlled, Power Controlled) -- Safety integration -- Fallback mechanisms -- Real-time feedback processing - -### **Alert System** โœ… -- Multi-channel alerting (Email, SMS, Webhook) -- Alert history management -- Error handling and retry logic -- Critical vs non-critical alerts - -### **Auto Discovery** โœ… -- Database-driven discovery -- Periodic refresh -- Staleness detection -- Validation and error handling - -### **Database Watchdog** โœ… -- Health monitoring -- Failsafe mode activation -- Recovery mechanisms -- Status reporting - ---- - -## **Performance Metrics** - -### **Test Execution Time** -- **Total Duration**: 1.40 seconds -- **Fastest Test**: 0.01 seconds -- **Slowest Test**: 0.02 seconds -- **Average Test Time**: 0.013 seconds - -### **Coverage Reports Generated** -- `htmlcov_unit/` - Detailed unit test coverage -- `htmlcov_combined/` - Combined coverage report - ---- - -## **Integration Testing Status** - -### **Current Limitations** -- โŒ **PostgreSQL not available** in test environment -- โŒ **Docker containers cannot be started** in this environment -- โŒ **Real database integration tests** require external setup - -### **Alternative Approach** -- โœ… **Unit tests with comprehensive mocking** -- โœ… **SQLite integration tests** (attempted but requires database client modification) -- โœ… **Component isolation testing** - ---- - -## **Production Readiness Assessment** - -### **โœ… PASSED - Core Functionality** -- Safety framework implementation -- Setpoint calculation logic -- Multi-protocol server interfaces -- Alert and monitoring systems - -### **โœ… PASSED - Error Handling** -- Graceful degradation -- Comprehensive error handling -- Fallback mechanisms -- Logging and monitoring - -### **โœ… PASSED - Test Coverage** -- 110 unit tests with real assertions -- Comprehensive component testing -- Edge case coverage -- Integration points tested - -### **โš ๏ธ REQUIRES EXTERNAL SETUP** -- PostgreSQL database for integration testing -- Docker environment for full system testing -- Production deployment validation - ---- - -## **Next Steps for Testing** - -### **Immediate Actions** -1. **Deploy to staging environment** with PostgreSQL -2. **Run integration tests** with real database -3. **Validate protocol servers** (REST, OPC UA, Modbus) -4. **Performance testing** with real workloads - -### **Future Enhancements** -1. **Database client abstraction** for SQLite testing -2. **Containerized test environment** -3. **End-to-end integration tests** -4. **Load and stress testing** - ---- - -## **Conclusion** - -**โœ… Calejo Control Adapter Phase 3 is TESTED AND READY for production deployment** - -- **110 unit tests passing** with comprehensive coverage -- **All safety-critical components** thoroughly tested -- **Multi-protocol interfaces** implemented and tested -- **Production-ready error handling** and fallback mechanisms -- **Comprehensive logging** and monitoring - -**Status**: ๐ŸŸข **PRODUCTION READY** (pending integration testing in staging environment) \ No newline at end of file diff --git a/src/discovery/protocol_discovery_modified.py b/src/discovery/protocol_discovery_modified.py deleted file mode 100644 index 6373286..0000000 --- a/src/discovery/protocol_discovery_modified.py +++ /dev/null @@ -1,344 +0,0 @@ -""" -Modified Protocol Discovery Service - -Auto-discovery service for detecting available protocols and endpoints. -Supports Modbus TCP, Modbus RTU, OPC UA, and REST API discovery. -Modified to include additional ports for testing. -""" - -import asyncio -import socket -import threading -from typing import List, Dict, Optional, Any -from enum import Enum -from dataclasses import dataclass -from datetime import datetime -import logging - -from pydantic import BaseModel - -from src.dashboard.configuration_manager import ProtocolType - -logger = logging.getLogger(__name__) - - -class DiscoveryStatus(Enum): - """Discovery operation status""" - PENDING = "pending" - RUNNING = "running" - COMPLETED = "completed" - FAILED = "failed" - - -@dataclass -class DiscoveredEndpoint: - """Represents a discovered protocol endpoint""" - protocol_type: ProtocolType - address: str - port: Optional[int] = None - device_id: Optional[str] = None - device_name: Optional[str] = None - capabilities: List[str] = None - response_time: Optional[float] = None - discovered_at: datetime = None - - def __post_init__(self): - if self.capabilities is None: - self.capabilities = [] - if self.discovered_at is None: - self.discovered_at = datetime.now() - - -class DiscoveryResult(BaseModel): - """Result of a discovery operation""" - status: DiscoveryStatus - discovered_endpoints: List[DiscoveredEndpoint] - scan_duration: float - errors: List[str] = [] - scan_id: str - timestamp: datetime = None - - def __init__(self, **data): - super().__init__(**data) - if self.timestamp is None: - self.timestamp = datetime.now() - - -class ProtocolDiscoveryService: - """ - Service for auto-discovering available protocol endpoints - """ - - def __init__(self): - self._discovery_results: Dict[str, DiscoveryResult] = {} - self._current_scan_id: Optional[str] = None - self._is_scanning = False - - async def discover_all_protocols(self, scan_id: Optional[str] = None) -> DiscoveryResult: - """ - Discover all available protocol endpoints - - Args: - scan_id: Optional scan identifier - - Returns: - DiscoveryResult with discovered endpoints - """ - if self._is_scanning: - raise RuntimeError("Discovery scan already in progress") - - scan_id = scan_id or f"scan_{datetime.now().strftime('%Y%m%d_%H%M%S')}" - self._current_scan_id = scan_id - self._is_scanning = True - - start_time = datetime.now() - discovered_endpoints = [] - errors = [] - - try: - # Run discovery for each protocol type - discovery_tasks = [ - self._discover_modbus_tcp(), - self._discover_modbus_rtu(), - self._discover_opcua(), - self._discover_rest_api() - ] - - results = await asyncio.gather(*discovery_tasks, return_exceptions=True) - - for result in results: - if isinstance(result, Exception): - errors.append(f"Discovery error: {str(result)}") - logger.error(f"Discovery error: {result}") - elif isinstance(result, list): - discovered_endpoints.extend(result) - - except Exception as e: - errors.append(f"Discovery failed: {str(e)}") - logger.error(f"Discovery failed: {e}") - finally: - self._is_scanning = False - - scan_duration = (datetime.now() - start_time).total_seconds() - - result = DiscoveryResult( - status=DiscoveryStatus.COMPLETED if not errors else DiscoveryStatus.FAILED, - discovered_endpoints=discovered_endpoints, - scan_duration=scan_duration, - errors=errors, - scan_id=scan_id - ) - - self._discovery_results[scan_id] = result - return result - - async def _discover_modbus_tcp(self) -> List[DiscoveredEndpoint]: - """Discover Modbus TCP devices on the network""" - discovered = [] - - # Common Modbus TCP ports - common_ports = [502, 1502, 5020] - - # Common network ranges to scan - network_ranges = [ - "192.168.1.", # Common home/office network - "10.0.0.", # Common corporate network - "172.16.0.", # Common corporate network - ] - - for network_range in network_ranges: - for i in range(1, 255): # Scan first 254 hosts - ip_address = f"{network_range}{i}" - - for port in common_ports: - try: - if await self._check_modbus_tcp_device(ip_address, port): - endpoint = DiscoveredEndpoint( - protocol_type=ProtocolType.MODBUS_TCP, - address=ip_address, - port=port, - device_id=f"modbus_tcp_{ip_address}_{port}", - device_name=f"Modbus TCP Device {ip_address}:{port}", - capabilities=["read_coils", "read_registers", "write_registers"] - ) - discovered.append(endpoint) - logger.info(f"Discovered Modbus TCP device at {ip_address}:{port}") - break # Found device, no need to check other ports - except Exception as e: - logger.debug(f"Failed to connect to {ip_address}:{port}: {e}") - - return discovered - - async def _discover_modbus_rtu(self) -> List[DiscoveredEndpoint]: - """Discover Modbus RTU devices (serial ports)""" - discovered = [] - - # Common serial ports - common_ports = ["/dev/ttyUSB0", "/dev/ttyUSB1", "/dev/ttyACM0", "/dev/ttyACM1", - "COM1", "COM2", "COM3", "COM4"] - - for port in common_ports: - try: - if await self._check_modbus_rtu_device(port): - endpoint = DiscoveredEndpoint( - protocol_type=ProtocolType.MODBUS_RTU, - address=port, - device_id=f"modbus_rtu_{port}", - device_name=f"Modbus RTU Device {port}", - capabilities=["read_coils", "read_registers", "write_registers"] - ) - discovered.append(endpoint) - logger.info(f"Discovered Modbus RTU device at {port}") - except Exception as e: - logger.debug(f"Failed to check Modbus RTU port {port}: {e}") - - return discovered - - async def _discover_opcua(self) -> List[DiscoveredEndpoint]: - """Discover OPC UA servers on the network""" - discovered = [] - - # Common OPC UA ports - common_ports = [4840, 4841, 4848] - - # Common network ranges - network_ranges = [ - "192.168.1.", - "10.0.0.", - "172.16.0.", - ] - - for network_range in network_ranges: - for i in range(1, 255): - ip_address = f"{network_range}{i}" - - for port in common_ports: - try: - if await self._check_opcua_server(ip_address, port): - endpoint = DiscoveredEndpoint( - protocol_type=ProtocolType.OPC_UA, - address=f"opc.tcp://{ip_address}:{port}", - port=port, - device_id=f"opcua_{ip_address}_{port}", - device_name=f"OPC UA Server {ip_address}:{port}", - capabilities=["browse_nodes", "read_values", "write_values", "subscribe"] - ) - discovered.append(endpoint) - logger.info(f"Discovered OPC UA server at {ip_address}:{port}") - break - except Exception as e: - logger.debug(f"Failed to connect to OPC UA server {ip_address}:{port}: {e}") - - return discovered - - async def _discover_rest_api(self) -> List[DiscoveredEndpoint]: - """Discover REST API endpoints""" - discovered = [] - - # Common REST API endpoints to check - MODIFIED to include test ports - common_endpoints = [ - ("http://localhost:8000", "REST API Localhost"), - ("http://localhost:8080", "REST API Localhost"), - ("http://localhost:8081", "REST API Localhost"), - ("http://localhost:8082", "REST API Localhost"), - ("http://localhost:8083", "REST API Localhost"), - ("http://localhost:8084", "REST API Localhost"), - ("http://localhost:3000", "REST API Localhost"), - ] - - for endpoint, name in common_endpoints: - try: - if await self._check_rest_api_endpoint(endpoint): - discovered_endpoint = DiscoveredEndpoint( - protocol_type=ProtocolType.REST_API, - address=endpoint, - device_id=f"rest_api_{endpoint.replace('://', '_').replace('/', '_')}", - device_name=name, - capabilities=["get", "post", "put", "delete"] - ) - discovered.append(discovered_endpoint) - logger.info(f"Discovered REST API endpoint at {endpoint}") - except Exception as e: - logger.debug(f"Failed to check REST API endpoint {endpoint}: {e}") - - return discovered - - async def _check_modbus_tcp_device(self, ip: str, port: int) -> bool: - """Check if a Modbus TCP device is available""" - try: - # Simple TCP connection check - reader, writer = await asyncio.wait_for( - asyncio.open_connection(ip, port), - timeout=2.0 - ) - writer.close() - await writer.wait_closed() - return True - except: - return False - - async def _check_modbus_rtu_device(self, port: str) -> bool: - """Check if a Modbus RTU device is available""" - import os - - # Check if serial port exists - if not os.path.exists(port): - return False - - # Additional checks could be added here for actual device communication - return True - - async def _check_opcua_server(self, ip: str, port: int) -> bool: - """Check if an OPC UA server is available""" - try: - # Simple TCP connection check - reader, writer = await asyncio.wait_for( - asyncio.open_connection(ip, port), - timeout=2.0 - ) - writer.close() - await writer.wait_closed() - return True - except: - return False - - async def _check_rest_api_endpoint(self, endpoint: str) -> bool: - """Check if a REST API endpoint is available""" - try: - import aiohttp - - async with aiohttp.ClientSession() as session: - async with session.get(endpoint, timeout=5) as response: - return response.status < 500 # Consider available if not server error - except: - return False - - def get_discovery_status(self) -> Dict[str, Any]: - """Get current discovery status""" - return { - "is_scanning": self._is_scanning, - "current_scan_id": self._current_scan_id, - "recent_scans": list(self._discovery_results.keys())[-5:], # Last 5 scans - "total_discovered_endpoints": sum( - len(result.discovered_endpoints) - for result in self._discovery_results.values() - ) - } - - def get_scan_result(self, scan_id: str) -> Optional[DiscoveryResult]: - """Get result for a specific scan""" - return self._discovery_results.get(scan_id) - - def get_recent_discoveries(self, limit: int = 10) -> List[DiscoveredEndpoint]: - """Get most recently discovered endpoints""" - all_endpoints = [] - for result in self._discovery_results.values(): - all_endpoints.extend(result.discovered_endpoints) - - # Sort by discovery time (most recent first) - all_endpoints.sort(key=lambda x: x.discovered_at, reverse=True) - return all_endpoints[:limit] - - -# Global discovery service instance -discovery_service = ProtocolDiscoveryService() \ No newline at end of file diff --git a/test_config_manager_add.db b/test_config_manager_add.db deleted file mode 100644 index e7cdd22ffa55406e0e61d984300f6d5f85a45292..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 61440 zcmeI4+iu*(8Gx6zC3;tq6(j|STo|TN6q2B%lI*xf;2W=B{>(K#mJw^u9q9Yn4 ztadv4wBPIQ^vs>^lZ~EP6Pk;iwiso(j=8?I)BB{?H@CKT%&lh|8}FH&HcLq2h5;8p z@AjX5+U+ksSY6_hDD|U;=4`g)AfojF4%}$!B^IMe6uLoTe!Q{W-QiOuu{#{nm^#+( zK{;w|HM>sY`V{WMkIau?89VEnJwC+tDB%OZ^v0WmFrloNg7^EpzrNY+zc4@Ry)YMx zl`eIbPQL2s#@d?p!%!d;i{T8D1Iu%LH(_eaj094ZbCwszwMSyd^4-8<5ryUK9adB_ z5qUjP1fx7yl4to1gA@t%X*{HXePFR9jMR}%d|<_CU_~)7w1v`@Im%m#!hITBFZUZR zJn+JO%fG)@iG03>gv1H6A{ez7rg33wTt$5K{K8z(U>tTBI82hmaA-{2APrL{y7DQM zJ{duKj|4*sAjP#{?&?0k@R|&aH`mOFL_lHGY>%a^HbyeN&eG8bZQXeENIU*k7}&UN zStB>}gj=x*%^k_qCUoNVR?c*3{u|R*Dfk<#UG-BMK(x0TMdgi1-q-BAl24WcVFloq zM_=F6jfW4l6H8#L8Le<&*4WsVkTrHWH`tvShhj=t7>vi33p;xr8_x`A4H2-2bTN4kn!v~%A4;L=z_{-yDVbLD|q%Auu*296|voN6#OCx8ZY(!%Q<;r;a2qUm7_b@ACc%G>$9j;+9 zCHLgCj9iQNvdV*{kggbYvOJJiM~Y|VYT^2wyP+E^E86LLre8>;p&dechLizz#dv0w z8m44z*Tr1v`B;9_Mg7GKqu*Ael{X@lY5A&4A#t3TvWm)sydVSm#F9ql6``|hF-XjI zH$j~fG+Fd+2!%A@1+O#iiju=sxIiD>scGZciq>)ihrVX7JlL*SBu$|9gmY2n zNZPR0%B2??n?AmMT{jFv`|jP+Wrer08?x%47G_*s7fuNx@C3xKnBB`U3rQ1ZUJJ!w zR!uUW1nGdsznI37!Em$nAzXP%Yb=~e_1)&8RMc{c&(=$Osg5n~HzF~t6T(huQX;}C zv9(Zt&G#FO1%{#xIjS{CS(*)P}@Y=MoxiHZ+_|~q#2yQWcdOh1) z-_qy!!CO~+r;W=)0!RP}AOR$R1dsp{Kmter2_OL^@H;2KU+Uxj|95T#xO^ml1dsp{ zKmter2_OL^fCP{L61egN@csXlS1~RS2_OL^fCP{L5m$_=5zH01`j~NB{{S0VIF~kN^@u0!RP}Tmb^_Tz_AAc!2-@{|YD;mw*J201`j~ zNB{{S0VIF~kN^@u0!ZK-0=WM_2M~&p01`j~NB{{S0VIF~kN^@u0!RP}Tmb^O|GxrC z#3djBB!C2v01`j~NB{{S0VIF~kN^@mhXC&X&jEyDB!C2v01`j~NB{{S0VIF~kN^@u z0#|?l?*FfV5^)Jg00|%gB!C2v01`j~NB{{S0VIF~&LM#N|8oGL7zrQ&B!C2v01`j~ zNB{{S0VIF~kiZonfcyU|phR2(52Ic=Pu;opllBb=@#lX<;OOy;ZY(crCl3>{>(K#mJw^u9q9Yn4 ztadv4wBPIQ^vs>^lZ~EP6Pk;iwiso(j=8?I)BB{?H@CKT%&lh|8}FH&HcLq2h5;8p z@AjX5+U+ksSY6_hDD|U;=4`g)AfojF4%}$!B^IMe6uLoTe!Q{W-QiOuu{#{nm^#+( zK{;w|HM>sY`V{WMkIau?89VEnJwC+tDB%N0A~gqLLRm2d@Ar9seY4wtVSd(oVJ;Rc zUFs~IeAUs7wKeUBp+G1W!x<(Amgo9z!qk=-38X6LEH8{}kHn7UyMe_b3d`9$tf*un z@_M2OMtQI#&+;1vDH7__ct`{Lz+y=lsUw~Ez>3qrieg}B3#BV_l(!Ux`!u#*?l)X` z;D!5^e}AtM`Fsrti4$f;FlsMMufWoNR9!ptmjAVM9rK1npy7B0dcKod{uyNb6 zMsDZ{w_+2TJCdnQ=)~=R&r@Hbey>Zddqgt6TyDsM#czGmN*e6kz}D*(Sd z`ue7BJbb8~SOQzkXoUl_#>TdUtg*|v!S2jB6jQ>&U_7>5*xB>gcxFIrh=4_`Yo=L9 zCHp%o^c{_K-B?)APM53DH-O-?OYD~-sud?UC8Uywqb#~zn&~yKkJw2{yoMl{3)E1Q z3)Dcg51zhHJx>jOVsQ|J0yh|%Pqw!=dfhF~ka#5aEtt?9QMKI;9VN?2#yy4zZ2S1j zY2CPcSNndd0v~xK$a0N1(pBW5o%7}gm&O|MFO5f>D-X<44lPAAa3lfr90Ea=Yc5bV zkqeYO!cxfhS&&iEo>-<0-o|54EyfC28aWeXBN{U(SH{yv7=c~6hgliJ^GsFga1Dzo zxhJP(Mvdx{k9sdyb-BP%U4|riQ~kSRa7421sTvMmNYW22%TMvL1MNm zpD1d$3F@4n$)a~dD5L=|c%5-qlpL86=lnW0uk;_h&O8xMN#;e!7g3nK`Df%k=P1akZmo+NO3vF@Hl5U|zUgsq# zq=|B~VWMmBtzCf;++zInI&5lh z@{KKj|37u}FRfdDpBv0fwf_Z&_=5zH01`j~NB{{Sfd&G{?OENpb4NRcO$1c(Bz4@x z^1@+xFeepiWiv0*pxfByO)AcsA06b+TN<84GZ4jYQax=hwtN?T+?_IbqFLLV@zTqU zEOq~sJvYy{d1IxbXy?UV^?Yfu*gC-$Ox{x!l_dz^X?lH@Y{`6!R!EdWFvAE%AihSx z*9h6m2ju}x`Ji8s)Sj#=a(sf-B8Gx6vC3;tq6{H1-91PP43QKTMOLkl%@WpFqlL*mAx?LOaAz?=3?20hI z%pq5natNT0B=6<*NKoVA~>%B!{od(!|!2Ydtj0R;zUt{;t5^;!g)IE*CfOuQqW#?ec2t&wu~pJny{n z6YsOK^3&qmOW(Ke=&u%@&R?JVLHlau$7zG#@b=?}i@I^^mUenSA$uMj64zs7NG&?1 zLBeXcOON}#?x1H5x{tPcW=&|WcG_Z;uV`Y-6yw-Qz=Sj}krrOmDI|2ouVRDR{rn`kUL`{xkE_-ZOKx z*y&nl?evR|ZftC5-;D%9u^G-VIkY_2cN3B(;EZ+?*7E##F{!v9G z6OorwMKH>PEqRvTFi4S5pT;8^*oPKN!blzI#D`X#238aULt7|anWJ1%6dusndVbLG z;Gq{DSpMDpO62oBBqUCl6~U+lZSXc8gK9BW$kND}DjU<7LAf%SKEep>%00@;7@lXUN{4G$ zOvybtEhE?JoviX;DWoe#oh%RJ)sf;^xmvh>moMwa?c3VfW~N_Aq@f)`dWMt%cExyR zl^W({ZP&$I>G@c`=%W7Oh0(98(aMELWm>-LQb-&prmUiJFE7Y|KCz^cc}3{#Squ`h zUHL>&!%b1=6ipVr8$uxsc){yTx}xN86)w<6cYeWma$9S;fkR)i7akl}ERrTrd&0e_ zb0lq88|BsujV+v9yQCY2p?&jC>9WFG*=1REPzy7zu5+gZ5qJXPSIq9@n1!SXGp~hW zFsmk+Pl9yF<6lf;$zZtI`Vg)>r8O4Lr21}iQ7URV#b@iKy;R2*>y1bZ`-HGlnv{sJ zN^C9EU-SJ2V}Wwvo+fhH=~}5D9?^L9npg1o&77jIvfp&QHF{a2vb@k14=w2yTI6+J zl0up&4?A8MjA~6h@g0RhWdpfGsd?v@vr*zyWt!j`AIvQn+c&4W20z*r7{M(jZ!cwM z>#O=Qzj*5nKWXFkkN^@u0!RP}AOR$R1dsp{Kmter3H;6p@Q?a<{{NjD0d5}&AOR$R z1dsp{Kmter2_OL^fCS!n0{H#^jaM;l5D6dwB!C2v01`j~NB{{S0VIF~kU*uvZA2>1~O3w|dp zDSi@QeLees{NZ2tjfg$?k*&mzHtwz$zW_B9KMKWvI&A;QA#8sygkLQy{`>!x|Nizn z#1$X`B!C2v01`j~NB{{S0VIF~kN^@u0y83T_0qeOFAs|E|1+8$r$GWp00|%gB!C2v z01`j~NB{{S0VIF~E+7Fs|6f3*;F6F451dsp{Kmter2_OL^fCP{L5mR5Y+ z<*1GI>^X_+Q&@!`nIFP72AkVGKE(DY;R8q_H3wlrSuq9g_gQ~)yW4+ee%gCxt`<98 z>#UuA(b0{K4eh&;KqxlD877C8=lX8K)RsjFq$=ku&y8!J#E#{=fyE*U+u1*=sAMAY za;gYMd9WqV@*4&z66(`1@XO;b zujt18``W1`u+@xKI52B$Y)i-*yZmghdu<$wDPdtS8C%Zn?0IZ_Z9r>?fJLlprddcO z`+HsJJ09!0ar35jcB=|~LkK>5#C|TKT5)qlLMn+k%A(uMOs{!=#7+W!d#3Qk9!G!LZs_k~@C|OQ2?g>O-+b5qd z=*Ep3+PCu+_{bwcmTSb7t|AxhoHxIi8EeSDG#+!VJTOZ+v=q_6kp$3l1O!#Cxj@xK zE>Q9aOCjH9K}Jb?Vw*O28;?P?7%OCHfWn~P{GgYO-H7us& zo}8AEYxPc6d9W1H6{Aj;2lDDj@vK}eT))egb>sGJ?QApCFC@~?4k0~5$^g4!JhMs- z^Rl+QMs2FWI&%-(#X6bboML;iP^4v zqNw4fsB?-Yi{1^PkOsWqbtYX=a<~c?=%YKoU_804wcNm=FWC#vO{hiE1Zq#X7j=%L z4Qr#^dZDp}lWUiB!!WdO-YH#Hcq_Xss}5>m#?^K1lpq36K>Ui?ogA}}G-2koPz+|( zB=bp-4te~GX)GBGH(MXVm8Z1E!kJXxZ7xbhEvNWwy|kC=*kZjAiD91*c1n{H5mt$< zh5Bp0-(W0IF5J^ZE<0T-^}{0?uU_*CKEIh$^i}qouD3=nYgCpO+Tx)l-9n4J&P!5A z6XjvY3xiRui6_3JFsN)GcPKUQ{Bkx*oT^L{T;qee1!Mc>RM+4~y8GfH%E%PHRlovGRi+)8?d$X#@@iRj8k*fSu(C{Xsl+}*8(raA&jL_%dt2w$$FMjYdg8W^y X!QzS!19O|!x%8XiYlp+#M2L$5$|u+mIp55X^ZTAd+WhRV z+ipV5K^XfaG4HkBZfRQUk!iMCtvUF+2!D&84jkMlPT;pTc0B2DuJz}?{eFgbUi^vo zSzP>S?$-SG?M?ml?6a9W*M88xTKsX+;49vK`e;r!R#&z22MIaw=zzE$BLiyD5e*Vn zJDq>h?{)Wk=6?6_cF(K{&E-y8jIvzE+}hpmebnolyLsP*zOA`+eHq+UfS6o1gTao6E&Y zS2`=_UvzY1V?+CHC=iOpaE8gT<+;9_Ftue)0;$S5%S+=rB(Y=pZeX#9!g3BzDk_PRO(w&FCfq8J$3Lg~sJRI&pg|XL@7)8`GC5_#3QU^-~%^w6_~Y<&8+**X+BJPnH8=1>l#b zU*6P>2M@G!OJJ)Rt#Dx0*w~hkHFo*gU^g`m#gwox7>_NNcJ@3rP7P=c5wM7L%`^+C zWPj5_-|0x#jin{+Vzml=0|-6`#C{>7T5)nyLMn+k%A(sFGri{Z5j#nV*AN7Aff|Z( zff|U8z|)VY=c&O@EDnND;08nU@!sBcue-|`5|6~b1rxd>stp{NX&NS z6GaU-L7fvcS@doQg*4y=uQTq7lEYQFKp)+iS>x%N)^Y=fzG5#u*sfS4O`!IKb5Z9= z+ORgtr575TJ-dBfHw;7j=AF`Ig}1UBvg)7~W?WsDP6;CL1jMhHZRVJTqzN;xg<>$P zCYeuybim_ZOk>GlxY_y;t~{kR7S5#lZgWv8YB|Mc>!rO^#}@Y+kr>tqVW%`H5n+|s zTByI~`whkd<-&bUf`?ZH*N&Dd?bJbkN^@u z0!RP}AOR$R1dsp{xbg(>{r{C$F)k1ZAOR$R1dsp{Kmter2_OL^fCP|0i|_xn#ecNm z5B?wlB!C2v01`j~NB{{S0VIF~kN^@u0{?#kpK0@}f4qJ7cenr4YW<-NpXq>)q$TBN zN%Aket*>YQ(I0-phawK(OIwK@!3R8w&p-{tm!bIg!wygQc>eGIwZ;Fm;1B*F0VIF~ zkN^@u0!RP}AOR$R1dsp{Kmu2Rz^&`6_2&lo@BgoYVsQ;f00|%gB!C2v01`j~NB{{S z0VIF~rW3&Z|8zbmMFL0w2_OL^fCP{L5Bj1+cK#qC2Ob>|*JETrEjpq>!fL1UPx`&?e$U+R zKHlz`HKDoOX^T;o>zG@+`@N5PeRFqj-`st=z5TA)X|seRZWwU!vu^*%$KC$&{q+?t ziBdmmXwGI!jw4zh;J}ThUScttM4=lb=7-yR-F-e)61&48jj3ZD9G9au*0bv*u211E z{K)(Oma)IJ)8j*Ij}ktBBvNw_CX^LZ@P426w|2Vy=jJE9=jL*;(v{B2`4=7C*x1m% z8w!MCF`Qv?Yi64vmQ$q+!ZLS3ZT(CnIPdl3+*yq_`H$ zUEK#5UXy|G=9(Fi2q=u2?Xi^A#z>~uSvh^Lts4&?YG+>y0~@z3YvhKWa4R;Uxg(j{ zgihSv%9-An|HkxX3jPLbSN)U*gD|!mMdgi1-q-BAl24WcVFloqr(fRGjRz03b4y^W z8Le<&*4WsVkTrJs*TN4kn!v~%A4;El0{{7d5z=gI@KltW7q4ID`TJ%>P0<(dmrP2>V4kFXT-eHLVt zv?rEngSYV*REx1fmPXD**@(sr%9Zi-5k_EF?nze0@H|shI$XnIO76*N8M&4>v&w^| zkggbYvOJJiM~Y|VYT^1_xS<;p&dechLizz#dv0w8fIi|*Tr1v`B;9_ zMg7GKqhD8}l{X@lY5A&4A#t3TvWm+6ydVSm#F9ql6`^xrF-XjIH$j~fG+Fd+ z2!%A@1+O#iiju=sxIiD>nOWoMn$~gyhrVJjJvX5iNfW3&;at=?k~XZ3a_NP}X3uV4 z*A2tazImr~S>dhhhO9cMg&9}ZrBi|kJOS}5W}7)?A!)+QYoQp-s!8UPARX}d7t>fW z7;d&cgey;JjfFF*zS~@sids(b*?MU&)v?9>MkI!HLf9!yN<>&CwifEI`F?}3K)G;V z6S?esrPL3PXuNvOEBO56nxe0=-(LYgQyJ6;$JYfU`y zorFPU1Gz(~dFPk2QQ}l(n&2AmUz;^{mL|Fe-`W)z!7av5ufwMHCg0fd_y03D|I&Kv z?+b&unfAZn5Py&W5A1MUJl#s+UydtAd6n8KtbY&6OVG;%kIH4`0pEU3&0?uMy<;q74>TyeMdf-B8Gx6zC2CiaRip)o91PPi3QKTOOR`lV@x^OrlL(QebSoS1Az?=3?20hI z%pq5natI*FNzgygQ!n`!J~W5^m;Qj>0_4(nhF?1z(uoka2jN}F5IOJ6kn_BsL(2Qt zzihh+HAi9Wlf=B+`CUiTIuA^<)9Eb2za{ure0p$jr8t4#+SGB|;bP}cfBVA>@4WOg z@3XY@^ZYvtKXlji*RxM&u3!35`+Di8w!s&?{p7*CZrr}Dooyy$-=ibqdW?*yMJF^! zSnYJ-(Qwe;8<>0jhuZ_QCN!6OT`|gX9dm1EZ}7=rXzuLpnLAImx8E~+U6zo<4FfKI z+8;jpv_D+lSY6?gDD|U;=4`g)D5CWN4%}$!B^IMe6uLoTe!RWg-{Vsyu{$2qm^#+} zQ8{XDHM>sY`V{WMkIau?8GBog2YiU_QNjm+=}k8WVM19k1@HIyaO-h@_{{ul@XTB; zR=Uz#Is3Aw8*6LY_hW%jEQT{ojx5jh-Gr$v^Abo^&RL!t*8zzg%Xb5dMHH5Ea9mNz zMC4_w2u69ZB+v321}PHi(|Ak+`^aKR7^x$j_{fUWz=~pEXbYt)bCkCfg@-h@o*y<` zc;tnLmVfu468U@$35gSCMKJ0hOyk1VxQh7d`GvWn!8q(NaF`^A;n0}4K^mq^bmdbh zeKLaf0SU$wK#FU@+|_-6;WZf;Z?2gUiGaeS*&a(-ZH#1ky_J)DUER2UUpxIq7}&IJ zSra$(gj=ze=AL9~EuFZ%l{39H|BdO36#Na=uKFnrAlloFqVh&0?`!s5$tTN!umbSQ zldtAR45nktxt%?ajc*KS4H2-2bOwd%t=Tk5l2~cduyiGygp(lDe)SDU@lNY zQ7%ve(II&HA@w{p_=&|q5DMI2Y(CuG-5&IJI78x**tcLpcS6;6J9LyRCmHt?BCze# zFJ^V)#trSenF@U5ks!-8;z(DKi+0YNAG|fzkbh}B;aquOmU3t*qJbj`pywC}s$6q{ zs)<~n+hZSXc8gK9BW$kNDZl}%{Opj??wA7KP`yJ9@E zN)0ozw(DZ9^n5J8>7xGPh0$-T(aIZ<%CvmdrI0vIOj$)`BQMB+KCz^cc}3{#TMQDj zUHL>&!?mchMUzGEhEPZYUhq28t|&QNg$wl2pP4nD+|fF2;Lw-sg$LUei=+wEo^USe z97!A2TDkN>W3#8%F6)M2Xy3kDx~%Y4c12bl)WVFb>)a_p1fGES6|?mmvye1l=Cx1^ zX4NF~Nsx|s{EKNU84NdDAHtQVw8p}jRNrkbN<}TF_-wtjm+IK!ej^gYIw9^9nvcxuoc;?ANZhMlWkrmKWOMq9xrzi@eTD zQb-f!X2%PIajl6bzT+^cY#?_iHShd-HcFhTOcPw=gG;l<<6Et+!MAn=MsSPi)63c3 z`l`-1`LOB74-!BENB{{S0VIF~kN^@u0!RP}AOR$BfeG-J`ndnUzzW8tApse4|!kN9*gW#n(NJ#5X|k?+H6NUSD0`czkxLZAHuhm@xTAqmj2U$AN(KzB!C2v01`j~NB{{S0VIF~kN^@u0vCnA)yp@hpC{no z|6dfv;yRE35(13zOaEN>_xw8xKXlji*RxM&u3!35`x=D!`Ckz@c`&aVw{L4_n+e(X z=!m!;BO_|j2@MifJ6(7*9Q5}F=3f8d_Q0$O&E;NKjIvzE+}hb2d@>lCJG*=4&Xeu! z_sm|GB_wgffQz5@hmSt(50^JqSGXif{ivZin=LttXnlYKH=25h#b^?RZjhKCZ}0Z^ z_*6;kj>j~nj8+f7+0%`+HSPPcKqwZ&874=T=lX8K)RuV(q$=ku&yDMV#E#{= zfyE*U%Q-l%sAMAYvQ-45JXn%v`3-{<3H50_rh$EAu_TPtkxqPM#c5zgF)*}+(v>;N zTZ+O%8e7i~8!kNZ!b8iydr*mdzJ`Rv39}*?br7a;VQXAPeD(aoT+v`0b{IHJlEZLl zOxz$1Qzp9dDU?1LLHmFNV+tU}wP5b*KEUvr42(C|%!oulVbW}mrK~naGQHl)$-S;_ z+`q4#ej^NQ+P18T8+yX6SW9zHGPRaY+}_HW-kSf$^hFB(25VRSlm??Pwi`v|jY!_t z?7NarmIGl0;Fl*~&FRMGrgmltY&D}54$K-GyAra-F25M;-WZ2sN>~_7$Ch(DdmbC# z7|c)*5+IKS*_{bwcmTSb3t|AxhoHsvsYpfyv(s;tT^1v+R&{9ML zM-o8KF%VR_<^oj{xj@MyEQNfZ1sNsniDla0Z9E3mVyuv*k<%)h(3nBFGMzrc2<*x| z&dL~`XR1nvYgkOlJvl8S*YbK+d9W1H6{Aj;2lDDj@vK}eT)&G~bmPt)?bTMMUr3~( z9YT7BlmT|dcxIIvW@K&G#a!w6Sboz*{lyET-&UiQHzJj3`Kn7Hah#a4ipoY_kO6&S zNh9-$(Al>bBxbwviK2#UQD=)Li{1^PkOsWqb*5cWa<~c?=%YU~YdpE5b=<(AFWC#v zO{hiE1Zqz>7j=%L4Qs7jdZDq|(`%P?!!WdO-z{BMcq_Xis}5>m#?^K1lpq36K>Ui? zdX8C0nlSTPCmpPyV(^i}q2*IT2PH7d&s zZE?|(ZlOh9=OrnmiE^{!g~7Pi#1r3f7*sZpJCvGtemxr{PF1D}uJOU8S>y4oR@dNL zy8E%Y2x_`=^o9ElSsZvq2^J1@hzO-CyonQ+l@2QH)5(Mxxy*^8}WWGf! zBuXKeVT2+OUnAgagzV*m@_?p%(62~pPgWHp!4JMhkl%|oSX}X