Overview
The Solution Lifecycle describes how solutions move from development through production. Three workspaces work together: Solution Center creates and manages solutions, Designer configures them, and Runtime executes them. Each stage has specific purposes - Development for building, Validation for testing, and Production for live operations.
→ Concept | How-to Guide | Reference
On this page:
through production using three integrated workspaces:
Key Concepts
- Three Workspaces: Solution Center, Designer, and Runtime form the complete
- environment
- Four Pillars Methodology: Structured approach for organizing Designer configuration
- Solution File (.dbsln): Single encrypted database containing all configuration
- Execution Profiles: Different runtime behaviors (Development, Validation, Production)
- Lifecycle Stages:
- Controlled progression from development through production
| Table of Contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Workspaces
|
Understanding the Solution Lifecycle
The Solution Lifecycle defines how FrameworX solutions progress from initial creation through production deployment. It encompasses three essential workspaces that work together to create, configure, and execute industrial automation solutions.
The Three Workspaces
EntrySolution Center
|
|
|
|
Solution Center
|
Designer
- Configuration workspace
- Module development
- Testing environment
- Build and validation
Runtime
- Execution environment
- Real-time operations
- Client services
- Performance monitoring
Lifecycle Flow
|
Solution Development Flow
1. Solution Center
- Create new solutions or open existing
- Manage licenses and resources
- Launch Designer for configuration
- Start Runtime for execution
- Monitor solution health
2. Designer Environment
| Pillar | Purpose | Modules |
|---|---|---|
| Data Foundation | Define data model | Unified Namespace, Assets, Tags, UDTs |
| Industrial Operations | Connect to field | Devices, Alarms, Historian |
| Business Operations | Process data | Datasets, Reports, Scripts |
| User Interaction | Present information | Security, Displays, Clients |
3. Runtime Environment
- Load configuration into memory
- Process real-time data
- Serve displays to clients
- Execute scripts and logic
- Store historian data
Project Development Stages
| Panel |
|---|
Create → |
| Panel |
Define → Develop → Validate → Deploy → Operate → Maintain |
Each stage uses a specific execution profile that controls runtime behavior:
| Stage | Environment | Execution Profile | Key Events and Characteristics |
|---|---|---|---|
| Create | Solution Center | n/a | SolutionDB file created |
| Develop | Designer | Development Profile | • Full editing, simulators • Full diagnostics and logs |
| Validate | Designer / Runtime | Validation Profile | • Limited editing, test modules • Performance metrics logs |
| Deploy | Runtime / Deploy | Production Profile | • Live equipment • Minimal overhead |
| Maintain | Designer / Runtime | According to task | • Designer DevOps & Track Changes tools |
Execution Profile Concept
Execution profiles allow the same solution configuration to behave differently based on environment:
| Aspect | Development | Validation | Production |
|---|---|---|---|
| Databases | Local SQLite | Test SQL Server | Enterprise SQL |
| Security | Minimal | Test credentials | Full authentication |
| Diagnostics | Full logging | Performance metrics | Minimal overhead |
| Data Sources | Simulators | Test devices | Live equipment |
| Changes | Online edits | Restricted | Protected |
Moving Between Stages
Development → Validation
- Complete initial configuration in Designer
- Test locally with Development profile
- Export solution configuration
- Import to validation environment
- Switch to Validation profile
- Begin formal testing
Validation → Production
- Complete all testing
- Obtain sign-offs
- Publish read-only version
- Deploy to production servers
- Switch to Production profile
- Monitor go-live closely
Solution Configuration Workflow
Define Data Model (Pillar 1)
- Create tags and naming conventions
- Build asset tree structure
- Define User-Defined Types
- Extend with TagProvider services
Connect Field Devices (Pillar 2)
- Configure communication channels
- Setup alarm conditions
- Enable historian collection
Add Business Connections and Logic (Pillar 3)
- Connect databases
- Create reports
- Write scripts
Add Security and Build Operator UI
(Pillar 4)
- Design displays
- Configure security
- Setup client access
Solution Management
Single File Architecture
All configuration stored in one .dbsln file:
- Tags and templates
- Device configurations
- Displays and scripts
- Security settings
- All module configurations
Benefits
- Simple deployment (one file)
- Easy backup and restore
- Version control friendly
- Consistent configuration
- No missing dependencies
Multi-User Collaboration
- Concurrent engineering on same solution
- Server-based central repository
- Granular access control
- Change tracking
- Conflict resolution
Version Control Integration
- Track Changes: Built-in change tracking
- Build & Backup: Create restore points
- Publish: Lock versions for production
- External VCS: Git/SVN integration
Best Practices Checklist
Development Guidelines
- Follow the Four Pillars sequence
- Test at each pillar completion
- Use templates for consistency
- Document configuration decisions
Progression Rules
- Never skip validation stage
- Always test rollback procedures
- Maintain separate environments
- Use appropriate execution profiles
Change Management
- Track all modifications
- Require approval for production
- Test changes in development first
- Document emergency procedures
| Excerpt |
|---|
Solution Lifecycle LinksExplanation - to understand concepts→ Modules / Solution Lifecycle Tutorials - to learn by doing→ Tutorials / Solution Lifecycle Tutorials How-to Guides - to accomplish specific tasks→ How-to Guides / Solution Lifecycle How-to Guide Reference - technical details→ Technical Reference / Solution Lifecycle / Reference |