Domain-Specific Cloud Business Operating System for New Power Systems: Concept, Key Technologies and Initial Applications

With the advancement of digitization in new power systems, numerous business applications need to orchestrate domain-specific functional modules in series or parallel, forming complex, long-chain computational tasks [1,2]. However, dedicated digital platforms independently developed by various business departments expose a series of critical operational issues when confronting large-scale, long-chain, and rapidly evolving business demands [3,4].

First, the massive scale of business operations lacks global resource coordination, making computational resources prone to crashes and compromising business reliability [5,6]. Both large-scale applications with massive concurrent tasks and long-chain businesses requiring multi-stage sequential execution share a common pitfall: each functional stage manages its own computational resources independently. Without global synergy, each stage then tends to maximize its local performance by initiating as many parallel computations as possible. When all stages operate concurrently under this paradigm, it can lead to physical server memory exhaustion, forced termination of business processes, and ultimately, data loss and computational interruption across the entire business chain [7,8]. For instance, during N-1 transient stability assessment of a power grid with over ten thousand buses, a single scenario snapshot can generate tens of thousands of power flow and stability analysis tasks, leading to hundreds of millions of service invocations across multiple sequential snapshots. Such massive concurrency of memory-intensive tasks can easily overwhelm cluster memory, causing the entire assessment request to crash [9].

Second, the execution of data read/write and computational tasks lacks specialized design, making it difficult to meet production timeliness requirements. Data silos across business stages necessitate an inefficient pre-processing workflow: data must be extracted and integrated from multiple distributed sources via middleware before computation can begin, resulting in a long preparation duration [10,11]. Meanwhile, generic scheduling strategies neither consider the priority and urgency of power system business nor coordinate with computational resource scheduling. This dual neglect fails to ensure that critical tasks are prioritized and completed within required time windows [12,13]. For example, an annual 8760-h sequential power flow simulation for a large grid requires aggregating multi-type data, such as topology, generator parameters, and historical renewable/load profiles, which are managed by disparate business modules. This fragmented data management can cause the preparation phase alone to consume hours. Once the computation begins, it traverses multiple sequential business stages, including scenario generation, unit commitment, power flow-constrained dispatch, stability verification, and security-constrained scenario adjustment, involving hundreds of millions of service invocations. This long-chain and resource-intensive process can monopolize cluster resources for an extended period if not properly scheduled, thus directly blocking the execution of more urgent tasks. Furthermore, the accumulation of such blocked requests can ultimately lead to chronic unresponsiveness or even a complete operational standstill [14].

Third, the escalating complexity of business platforms leads to explosive growth in compatible development and deployment efforts, rendering maintenance processes unsustainable. For program integration, when power system domain experts propose new specialized models or algorithms, they must rely on software developers to simultaneously write the whole front-end and back-end code, forming an operational close-loop. This dependency creates a long and costly path from innovation to production validation [15,16]. For data connectivity, each newly introduced business necessitates the development of dedicated data-bridging middleware with all related existing businesses. As the variety of businesses grows, the number and management complexity of these data middleware components increase exponentially, making platform operation and maintenance exceedingly difficult [17]. For instance, in grid-connection stability analysis, engineers must frequently integrate specialized device models to adapt to the rapid iteration of power electronic devices—a process that alone can consume over 80% of the analysis cycle [18]. Meanwhile, to enable comparison of results across different simulation engines, dedicated one-to-one data-conversion interfaces must be developed for each engine pair. This paradigm results in thousands, or even on the order of (1000 × N²), distinct middleware components. The compounding effect of these two factors creates a massive maintenance burden that is ultimately unsustainable for the platform.

Confronted with these challenges, both industry and academia have made numerous attempts based on mainstream digital solutions, such as microservices architecture [19] and Cloud-Native Operating Systems (OS). For resources, the Cloud-Native OS supports dynamic resource adjustment through autoscaling techniques, but these strategies mainly rely on general metrics, lacking coupling with specific task attributes and business logic [20]. This leads to problems such as under-provisioning, over-provisioning, or inefficient scaling, resulting in underutilized computing power and sacrificed efficiency. For efficiency, existing research has proposed task scheduling algorithms that consider power system business attributes [21,22]. However, these approaches focus solely on task scheduling and do not incorporate computational resources as decision variables in the overall optimization problem, leading to resource idling and slow response times. For maintainability, Continuous Integration/Continuous Delivery (CI/CD) practices provide an automated deployment pipeline, and research on power system ontology data middle platforms has proposed unified ontology data object designs [23,24]. Yet, due to the lack of standardized abstraction and systematic organization for all power system business programs and data, current generic approaches cannot support the independent, agile integration of domain-specific models/algorithms or enable closed-loop data flow across the entire business chain. Consequently, point-based solutions or incremental improvements have failed to fundamentally address the systemic challenge formed by the coupling of resource, efficiency, and maintainability issues. Constructing a systematic architecture for the unified management of power system digital business objects remains a significant bottleneck.

To break through the bottleneck, this paper proposes and develops a domain-specific cloud Business Operating System (BOS) for new power systems. Positioned as a holistic architectural and industrial application article, it focuses on demonstrating the system-level design completeness and functional utility of this new paradigm, rather than on the incremental optimization of any individual component, with the main contributions as follows. First, the concept of BOS is proposed, a novel architectural paradigm designed to achieve unified business resource management for four key objects (containers, tasks, programs, and data) through three systematic approaches. Second, an innovative mechanism for task-container co-scheduling is designed, effectively overcoming the computational efficiency bottlenecks inherent in traditional architectures. Third, standardized pluggable interfaces and a full lifecycle management mechanism for domain-specific programs are established, enabling flexible and agile integration of massive models and algorithms. Forth, a unified business data foundation is constructed, ensuring semantically consistent, high-performance data connectivity across the entire business chain.

The remainder of this paper is organized as follows. Section 2 elaborates on the design philosophy and architectural scheme of BOS, justifying its characterization as an operating system. Section 3 provides an in-depth analysis of BOS’s key technologies in managing containers, tasks, programs, and data. Section 4 demonstrates preliminary application cases built upon BOS. Finally, Section 5 concludes the paper and outlines future research directions.

Before proposing the architecture of BOS, we first review the application of the generic microservices architecture and Cloud-Native OS in power system digital platforms. They provide conventional platform design and functional modules, forming a foundational framework. However, when dealing with domain-specific business requirements, significant capability gaps emerge, as summarized in Table 1.

Building upon the generic microservices architecture and Cloud-Native OS, BOS introduces pivotal enhancements tailored to power system business characteristics. As illustrated in Figure 1, we propose a clear management matrix. This matrix defines a systematic approach to managing the four core objects (containers, tasks, programs, and data) through three methodological columns: (a) Standardized Definition, (b) Indexed Organization, and (c) Dynamic Management. The first two columns are instantiated as two domain-specific fundamental design schemes: the Object Standardized Definition Scheme and the Object Indexed Organization Scheme, respectively. To address the dynamic management needs shown in the third column—namely, task-container co-scheduling, program dynamic integration, and data read/write strategy optimization—three dedicated core plugins are developed and integrated into the conventional platform modules.

The details of these two design schemes and three plugins are elaborated as follows, illustrating how they directly address the capability gaps outlined in Table 1.

Scheme 1: Object Standardized Definition Scheme (OSDS). It establishes unified representation contracts for the four object types—Containers, Tasks, Programs, and Data—providing a consistent foundation for their identification, interaction, and scheduling. This scheme is a prerequisite for an indexed organization and dynamic management.

Scheme 2: Object Indexed Organization Scheme (OIOS). Building upon the OSDS, OIOS implements a systematic indexed organization for the four core objects, creating a system-wide metadata catalog and relationship map. This enables precise object localization, efficient association, and rapid retrieval, which constitutes the domain-specific enhancement required for the Database Organization Scheme.

Plugin 1: Task-Container Co-Scheduling Plugin (TCCSP). It establishes the core mechanism for real-time cooperative scheduling between tasks and computational resources, enabling efficient and reliable execution of large-scale concurrent tasks. By integrating the decision logic of the Container Management Module into the Scheduler, it transforms the scheduling paradigm from a passive model with fixed resources to a task-resource cooperative one. This satisfies the co-scheduling requirements for both the Scheduler and the Container Management Module.

Plugin 2: Program Load/Unload Management Plugin (PLUMP). It establishes a full lifecycle management mechanism for programs based on CI/CD principles. This mechanism automates the closed-loop process for custom models and algorithms, including upload, validation, registration, discovery, loading, and unloading. This satisfies the dynamic integration requirements for both the User Interface and Power System Business Services.

Plugin 3: Data Read/Write Optimizing Plugin (DRWOP). It establishes an intelligent planning mechanism for data access. This mechanism optimizes the execution paths for business data read/write requests, ensuring efficient access to the database cluster. This satisfies the intelligent routing requirement for the Data Read/Write Services.

To sum up, BOS is a domain-specific cloud operating system designed to address the three core production challenges outlined in the Introduction. The mapping between these challenges and the key solutions provided by BOS is summarized in Table 2.

The name “Business Operating System” originates from its fundamental similarities to generic operating systems in terms of core functionality and management philosophy. Its justification as an OS is demonstrated through the following two complementary comparisons.

The first comparison demonstrates BOS’s functionality extension by contrasting its scope with that of the generic Cloud-Native OS, highlighting its tailored response to power system digitization challenges. The Cloud-Native OS, such as Kubernetes, abstracts fundamental resources (e.g., computation, storage, networking) and supports full lifecycle management of containers. However, the digitization of new power systems demands the abstraction and management of not just containers, but also tasks, programs, and data, as illustrated by the management matrix in Figure 1. Consequently, BOS’s functional scope must extend from the infrastructure to the business layer, surpassing that of the generic Cloud-Native OS. To clearly illustrate this functional leap, Table 3 presents a systematic comparison between the two systems based on the 12 management methodologies defined in Figure 1.

As shown in Table 3, the Cloud-Native OS provides mature support for container standardization and indexing, along with basic mechanisms for task forwarding, container resource provisioning, and database organization. However, this capability is confined to the infrastructure layer. For the program and data objects that encapsulate the core semantics of power system business, the architecture lacks native, systematic management capabilities. Specifically, while it offers generic data definition and organization features through standard database products, it lacks the domain-specific semantic models and indexed organization schemes required to efficiently manage power system business data. Moreover, its task scheduling and resource scheduling mechanisms operate in isolation, designed for different objectives without intrinsic coordination, which prevents global optimization.

In contrast, BOS establishes a new paradigm centered on the unified orchestration of business objects. By applying systematic, standardized definitions and an indexed organization to the four core objects, and empowering them with dedicated intelligent plugins, BOS achieves an evolutionary leap from a generic Cloud-Native OS to a domain-specific business OS. This transformation provides a structured and intelligent foundation for upper-layer power system applications.

The second comparison demonstrates the significant philosophical isomorphism between BOS and the classic Desktop OS (e.g., Windows, Linux) at the architectural level. The Desktop OS manages a computer’s physical hardware resources by abstracting processes, files, memory, and device drivers, thereby providing a unified runtime environment for upper-layer software [25]. Although BOS manages digital business resources of power systems rather than physical hardware, its design philosophy is highly isomorphic to that of the Desktop OS: both abstract underlying heterogeneous resources through standardized interfaces and provide a unified, efficient, and secure runtime environment for upper-layer applications. To systematically demonstrate this architectural isomorphism, Table 4 provides a structural analogy between the two systems across two dimensions: management objects and core modules/schemes.

In summary, BOS successfully applies the core abstraction and management paradigms of the Desktop OS at the architectural level to power system digitization. The analogies detailed above collectively demonstrate that its design is not a superficial metaphor but a genuine structural isomorphism. Therefore, defining BOS as a domain-specific cloud business operating system is an architecturally precise description of its role as a foundational platform for digital business in new power systems. In essence, just as the Desktop OS provides a universal abstraction layer over heterogeneous hardware, BOS provides a universal abstraction layer over heterogeneous digital business resources, forming the strategic infrastructure for their efficient and stable orchestration.

The realization of BOS’s two foundational design schemes and three core plugins relies on five key technologies.

Standardized definition must be applied to all four object types. For containers, mature solutions exist, and BOS adopts the definition methodology from established products like Docker.

To bridge the user’s perspective of macro business requests with the system’s perspective of micro computational units, BOS introduces a hierarchical abstraction model—Task Set and Task—with standardized definitions for their structures and associated attributes, as shown in Figure 2. This design ensures clear management visibility and efficient scheduling execution.

A task set serves as the macro unit for business request management. It corresponds to a complete business request initiated by a user and serves as the macro-level unit for business management. For example, an annual operation mode power flow verification request can be regarded as a task set. Its primary function is to create and maintain a unified context that propagates to all its subordinate tasks. This context includes a globally unique task trace identifier, user/project/scene information, and global task logs, thereby ensuring end-to-end traceability of the entire business chain.

A task represents the micro and minimal schedulable execution unit within a task set. It acts as the basic execution unit for the scheduler. When a business request requires calls to multiple services, the caller service decomposes a task set into several tasks. For instance, the aforementioned annual power flow verification task set can be decomposed into 8760 (365 days × 24 h) independent hourly power flow calculation tasks.

As the execution carrier, a task associates all necessary elements for its execution through the following four standardized interfaces:

To enable automatic integration and full lifecycle management of custom programs, BOS enforces a mandatory code specification for business services. Centered on the domain-specific Program Slot mechanism proposed by BOS, this specification systematically decouples business logic and model/algorithm implementations from the generic service framework, as illustrated in Figure 3.

The BOS code specification is hierarchically organized, clearly defining the responsibilities of each directory and physically separating the pluggable program slots from the service. This structure comprises several key elements:

Specifically, the program slot is a pre-defined, standardized integration point. Each slot defines a precise contract for a category of models or algorithms, specifying required input/output parameters, data structures, and the invocation method. Any compliant program can be integrated as a standardized component. A complete pluggable program consists of three elements: (1) Base I/O Structure Definitions, pre-defined by experts and stable long-term; (2) Core Implementation Code, where domain experts implement the specific logic; and (3) Generic Invocation Interface, which adapts actual inputs/outputs to the slot’s standard contract, bridging the core implementation and the standardized slot.

As shown in Figure 2, BOS standardizes all data involved in task execution into three core categories: Input Data, Output Data, and Task State Data. The overall scheme is introduced in Section 3.1.1. This section details the standardization schemes for the power system ontology data (a core part of the input) and the power system business result data (the output).

Power system ontology data is structured as a hierarchical unified model based on ontological principles. As presented in Table 5, this model comprehensively characterizes the spatiotemporal characteristics of power systems through a multi-dimensional classification. The classification is organized first by object level, distinguishing system-level element data, entity-level element data, and their relationships. Second, it considers time-variance, subdividing data at each level into time-varying and non-time-varying attributes. Finally, it is refined by semantic functionality, with data classified according to its precise business meaning.

Power system business result data is standardized into a set of structured descriptive metadata to ensure the results are locatable, interpretable, and traceable. Its key attributes include: (1) Business Type, which identifies the business category of the result; (2) Task Identifier, which provides a precise index to the task that generated this result (detailed in Section 3.2.1); and (3) Result File Storage Address, which points to the physical or logical location of the result data file.

Building upon the standardized definitions, BOS implements a systematic indexed organization for the four core objects. This process forms concrete metadata indexing schemes within the database cluster.

For containers, BOS establishes a three-tier resource relationship index that maps the hierarchy from physical servers to service containers, and finally to the service instances, as shown in Figure 4. This index records the real-time state, resource quotas, and ownership relations of entities at each level, providing a precise topological view for global resource monitoring, scheduling, and fault recovery. The specific indexed organization scheme is as follows:

To ensure full lifecycle observability and traceability, BOS organizes all tasks around a central Task Index Table, constructing a task-mediated data traceability chain. Upon creation, each task is immediately linked to its parent task set based on execution context and simultaneously indexes its designated input data and output results. This design positions the task as the definitive reference points that anchor and link all associated data throughout the computational workflow, with the detailed relationships illustrated in Figure 5.

The traceability chain in Figure 5 is an organic whole formed through indexed relationships between six core elements:

Based on the above indexed organization, BOS can achieve three key data traceability capabilities.

First, it enables automated aggregation of task results for a task set. To obtain a consolidated outcome of a macro business request, BOS first queries the Task Set Index Table to retrieve all associated Task IDs. It then checks the task state recorded in each corresponding Task Index Table. For successful tasks, the system follows its output data index to locate and aggregate the complete set of result files. For tasks in other states, their state and relevant logs are also automatically aggregated into the summary report. This process provides a comprehensive execution summary for the entire business request.

Second, it supports lightweight visualization of any task result. When a user needs to view a specific business result, BOS first locates the corresponding output data file in the Output Index Table using the provided Task ID. Simultaneously, it uses the same Task ID to query the Task Index Table, retrieving the scenario index that points to the exact version of power system ontology data used as the task’s input. This indexed retrieval ensures that every result can be visualized with its precise ontology data, while eliminating the need to redundantly store ontology data within the result files themselves, achieving both data consistency and storage efficiency.

Third, it facilitates automated backfilling of validated results into the Power System Ontology Databases. When a validated business result needs to be written back to Power System Ontology Databases to enable the next business step, BOS employs an indexing method similar to that in the second capability, using the Task ID to associate the result data with its exact input ontology records. This enables users to efficiently execute a sequence of business steps within the same scenario, where the output of one step becomes the refined input for the next. For instance, in a scenario sequential simulation, after solving the Unit Commitment problem, BOS can help users to automatically backfill the generator on/off schedules into the corresponding entity state records. This updated state is then directly used as input to the subsequent Active Power Dispatch step, which schedules the precise power output for the committed units.

For programs, BOS constructs a tree-structured organizational index for the microservices cluster of the business platform, using metadata to record each service’s level of integration support for custom algorithms and models. Simultaneously, it establishes a custom program index table to ensure global discoverability and manageability of custom programs. The overall program indexed organization scheme and its relationship with other platform components are illustrated in Figure 6.

To clarify the service architecture and integration capabilities of the entire platform, BOS maintains a service index tree. This tree hierarchically organizes business domains and their subordinate services, annotating each service with key metadata to explicitly indicate whether it supports the integration of custom algorithms and models via program slots. This metadata provides PLUMP with a whitelist of services capable of integration.

To enable program loading/unloading for PLUMP, BOS builds the Custom Program Index Table. This table records the integration capabilities and core information of each custom program, including:

Based on the standardized data model, BOS constructs a unified data foundation. As illustrated in Figure 7, this foundation encompasses the Platform Databases, the Power System Ontology Databases, the Business Result Databases, the Model/Algorithm Databases, and repositories for programs. Crucially, this foundation is architected with a heterogeneous storage strategy, where each type of data is persisted in the database best suited to its access patterns and structural characteristics, achieving efficient data access. Given that main index relationships have been detailed in Sections 3.2.2 and 3.2.3, this section focuses on the physical storage and its indexed organization schemes for the core business data: the ontology data and the result data.

For Power System Ontology Databases, BOS implements a relational-graph hybrid architecture to balance the needs for complex relationship traversal and high-performance multi-attribute queries, as depicted in Figure 7. This hybrid design consists of two complementary components.

First, structured attribute data is stored in relational databases. All categories of system-level and entity-level element data from Table 5 are persistently stored in relational database tables. For example, system data E_system is stored in table T_system. Under this architecture, relational databases excel at multi-attribute, precise queries and efficient retrieval across data relationships with limited hops.

Second, complex relationships are stored in graph databases. The organizational and topological relationships data among entity-level elements from Table 5 are stored in graph databases. As shown in Figure 7, BOS adopts a hierarchical graph model with layers such as Grid and Station to directly represent containment relationships. Within each layer, connectivity between elements is modeled as topological edges. This structure is inherently optimized for relationship-intensive operations that involve multiple hops or recursive traversal, such as topology analysis, connectivity verification, and fault impact analysis. Furthermore, to accelerate specific queries, key descriptive attributes (e.g., name, type) are also stored on the corresponding graph nodes.

Collaboration between the graph and relational databases is achieved through identifier mapping. When handling a complex business request that requires combined relationship and attribute retrievals, BOS executes a two-phase query. It first leverages the graph database for rapid entity positioning and relationship traversal. The resulting set of entities is then used to precisely retrieve their detailed attribute data from the relational database. This collaboration is enabled by a strict one-to-one mapping between entity records in the relational database and corresponding nodes in the graph database, both linked by the same globally unique identifier for each entity.

For the Business Result Databases, BOS adopts a relational-file hybrid architecture to balance management efficiency with read/write performance for typically voluminous and structurally diverse result data. This architecture also involves two coordinated parts.

First, the metadata of business results is managed in a relational database. As shown in the Output Index Table in Figure 5, a relational database table records all business result metadata and uses the file address information to link the physical locations of the corresponding result files.

Second, the actual voluminous result data is stored in a high-performance distributed file system. A flexible file organization strategy is employed to optimize for diverse retrieval needs, which includes partitioning a single logical result into multiple physical files along specific dimensions (e.g., by time step or device type), and generating redundant copies in different formats (e.g., one optimized for time-sequential access, another for querying by device). This strategy ensures efficient retrieval of results tailored to specific business needs.

Collaboration between the relational table and the file system is mediated by the file address. When a business service needs to retrieve a specific result, it first queries the Output Index Table to obtain the available file addresses. Based on the specific retrieval requirement, the service then selects the most appropriate files and uses their addresses to directly access the corresponding files in the distributed file system.

Based on the standardized definitions and indexed organization of both tasks and containers, BOS implements a unified task-container co-scheduling mechanism. Its core function is to dynamically match the execution of tasks with the provisioning of computational resources, closing the loop between workload demand and resource supply. The two interacting components that constitute TCCSP are detailed as follows.

The primary responsibility of the Task Scheduling Module is to manage the lifecycle of computational tasks, from receiving macro business requests to scheduling the execution of their constituent tasks onto appropriate computational containers, with its technical architecture shown in Figure 8. It operates in coordination with the Container Scheduling Module to form a closed-loop optimization system.

The Task Scheduling Module operates on an event-driven mechanism, cyclically executing the following steps.

Step 1: Event Triggering and Task Registration. When a new task arrives, it is registered in the Task Index Table, its state is initialized to “pending”, and it is placed into the Task Queue. Concurrently, a periodic timer is activated to trigger the scheduling cycle for this queue.

Step 2: Task Scheduling Decision—Container Selection. When triggered by the timer, the Container Selecting submodule initiates a scheduling cycle. Its decision is based on a snapshot of the current container resource state, which is kept consistent during this cycle. The decision process employs three core algorithms: (1) Algorithm A₁ (Task Forecast): Predicts a task’s execution duration based on the assigned container’s resources, power system scale, business characteristics and historical performance data; (2) Algorithm A₂ (Task Priority Evaluating): Calculates a dynamic priority score for each pending or retrying task, considering its business criticality and urgency; (3) Algorithm A₃ (Task Scheduling Optimization Solver): Using the predicted time from A₁ and priority weights from A₂ as inputs, this algorithm solves the optimization problem for assigning tasks to containers.

The optimization problem solved by Algorithm A₃ is formally defined as: minimizing the global weighted average completion time of tasks under the constraints of task deadlines and available container resources. The decision variable is defined as a_tp ∈ {0, 1}, indicating whether task t is assigned to service container p. This problem is formulated as:

where:

If the optimization problem determines that current resources are insufficient to meet task deadlines, it does not output an infeasible assignment. Instead, it immediately sends a resource adjustment request through the Container Co-Scheduling Interface to the Container Scheduling Module. After dynamic resource scaling, the Task Scheduling Module re-runs the optimization in Algorithm A₃ with the updated resource state.

Step 3: Task Dispatch and Execution. Once a feasible assignment scheme is determined, the Tasks Consume submodule is notified. It pulls the scheduled tasks from the Task Queue, updates their state in the Task Index Table to “executing”, and forwards the execution requests to the assigned containers.

Step 4: Task State Update Based on Result. Upon receiving the execution result from a container, the Task Scheduling Module updates the task’s final state in the Task Index Table to “success”, “failed”, or “retrying”.

The primary responsibility of the Container Scheduling Module is to dynamically adjust container resources, through actions including startup, shutdown, and resource quota modification. This module operates in two complementary modes: (1) the normal mode, where it optimizes resource allocation to reduce costs based on a feasible task schedule; and (2) the guarantee mode, where it urgently provides additional resources when the Task Scheduling Module cannot find a feasible schedule, ensuring that a solution becomes possible. Its technical architecture is shown in Figure 9.

The Container Scheduling Module also operates on an event-driven mechanism. Its workflow, which differs slightly between the two operating modes, cyclically executes the following steps.

Step 1: Event Triggering and Input Preparation. A new resource scheduling cycle is initiated by one of two events: (1) In normal mode, the cycle is triggered by a periodic timer signal. The input is a feasible task-container assignment scheme obtained from the Task Queue. (2) In guarantee mode, the cycle is triggered by a resource adjustment request from the Task Scheduling Module. Since no feasible assignment scheme exists, the Container Scheduling Module prepares a relaxed virtual assignment scheme by associating each pending or retrying task with multiple candidate containers randomly, thereby formulating a resolvable optimization problem.

Step 2: Resource Scheduling Decision. When triggered, the Container Resource Scheduling submodule initiates a decision cycle. Based on the prepared input, it formulates and solves a resource optimization problem. The decision variables are the state variable u_p and resource allocation variable r_p for each container p, consistent with their definitions in Formula (1). If multiple types of resources are considered, the scalar r_p can be generalized to a vector r_p = (r_p1, r_p2, …). This problem is mathematically formulated as:

where:

Step 3: Instruction Execution. The Container Resource Scheduling submodule translates optimization results into commands such as starting up, shutting down, or adjusting the resource quota of specific containers. These commands are dispatched to the Cloud-Native OS for reliable execution.

Step 4: Iteration and Convergence Towards Global Co-Scheduling Optimum. After command execution, the Resource Monitor captures the updated global resource state. This new state closes the control loop through two concurrent feedback mechanisms. First, it updates the local state, which becomes the initial condition for the Container Scheduling Module’s next decision cycle. Second, it provides real-time feedback to the Task Scheduling Module by sending the updated container parameters (u_p, r_p) through the Task Co-Scheduling Interface. This updated resource snapshot directly enables the next round of Container Selecting decisions.

Through this iterative feedback, the two modules co-evolve: the Task Scheduling Module makes its assignment decisions using the up-to-date container resource parameters (u_p, r_p) fed back from container scheduling, while the Container Scheduling Module adjusts resources based on the demand from task scheduling. This closed-loop interaction allows TCCSP to progressively converge towards a globally efficient state that jointly optimizes task completion timeliness and resource utilization.

Based on the standardized definition and indexed organization of programs, BOS constructs the PLUMP for the lifecycle automatization of domain-specific model and algorithm programs, decoupling their integration from the traditional software development and deployment pipeline. Its technical architecture is illustrated in Figure 10, and its core functionalities are realized through three interconnected workflows.

The first workflow automates program integration from development to the user interface. This process ensures that a submitted program becomes immediately available for use. Specifically, after a user submits custom programs, PLUMP pushes them to the Custom Programs Repository and compiles it into an OS-specific dynamic link library (e.g., a .so file). It then parses the program’s interface, validates its compliance with the target slot’s standardized contract, and records its metadata in the Custom Program Index Table. Consequently, the user interface dynamically fetches the updated list of all available models/algorithms and their configuration parameters from this index table, rendering corresponding selectors and form elements without manual intervention. This end-to-end automation allows domain experts to integrate new capabilities independently and see them reflected in the application immediately.

The second workflow enables the dynamic plug-and-play integration of private programs with safe isolation. Designed for agile testing and evaluation, this workflow adheres to a security-first principle to isolate unvetted code from the stable production environment. It implements two coordinated mechanisms. First, when a business service needs to invoke a private program, PLUMP locates the program’s storage address through the Custom Program Index Table. The service can then load the corresponding precompiled library files into the target program slot within a running service container, enabling immediate execution without restart. Second, a safety isolation mechanism is enforced in coordination with TCCSP. Requests for private programs are routed exclusively to service containers running in trial mode, which run with reduced system privileges to mitigate risks.

Third, Public Program Integration: Two-Stage Release. This workflow governs the secure promotion of a validated custom program to an official platform component. First, the program undergoes a formal review to grant its public state. Upon approval, PLUMP merges it into the Official Program Repository and triggers an automated pipeline to rebuild and redeploy the affected service containers in the trial mode. After confirming correctness and stability during this trial phase, the service containers are switched to the launched mode, completing the two-stage integration process.

Based on the standardized definition and indexed organization of data, DRWOP determines how to plan the most efficient access path for specific data read/write operations. Specifically, DRWOP abstracts the entire data space as a data relationship network and models the read/write execution process as an optimal path search problem.

First, DRWOP models all data and their read/write dependencies as a directed graph network G = (V, E), where the vertex set V represents all data, and the edge set E represents read/write operation paths. The edges are divided into two categories: (1) Read Edges E_read: A directed edge (u, v) ∈ E_read indicates that data v can be retrieved starting from data u. These edges are annotated with attributes that define the retrieval path (e.g., via relational or graph databases) and any required additional conditions. (2) Write Edges E_write: A directed edge (u, v) ∈ E_write indicates that data u must be written before data v, representing transactional dependencies in data writing. These edges are similarly annotated with attributes characterizing the retrieval path.

Based on the above abstraction, the search for an optimal execution path for a given read/write request can be defined as a mixed-integer programming problem. For a read request querying target data T under given data condition S, the optimization problem can be formally defined as minimizing the time consumption of the data read request, subject to the constraints that both the start and end vertices are reachable, and the path is continuous. The decision variables are defined as binary variables y_uv ∈ {0, 1}, indicating whether the edge (u, v) is selected as the execution path for data reading. This problem is formulated as:

For a write request targeting data T, the optimization problem can be formally defined as: minimizing the time consumption of the data write request under the constraints that the endpoint is reachable and transactional dependencies of data writing are satisfied. The decision variables are defined as binary variables z_uv ∈ {0, 1}, indicating whether the edge (u, v) is selected as the execution path for data writing. This problem is formulated as:

where:

By solving the above model, DRWOP is able to plan an access path with the shortest time consumption for each read/write request. This path clarifies the sequence and method of data retrieval or the transaction execution sequence for data writing, thereby further optimizing runtime access efficiency on the basis of the existing data foundation.

To validate the practical efficacy of BOS, several applications have been developed around power system planning and operation business based on BOS, forming the BOS-based Power System Business Platform. The following case studies, conducted on a real-world regional power grid in China, demonstrate how this platform systematically resolves the three core challenges of traditional architectures:

Based on the unified data foundation constructed with BOS, this case study demonstrates seamless data flow by executing a complete steady-state planning and security validation workflow. The steps are as follows.

Step 1: System Modeling. Prepare the Non-Time-Varying Element data categories from Table 5, including E_System, E_SC, E_Entity, E_SM, E_DM, E_CE, and Relationship, to construct a basic system model without state data.

Step 2: Initial Scenario Snapshot Establishment and Validation. Configure the Entity State data E_ES to form an initial scenario snapshot. Perform power flow calculation and steady-state security assessment for this snapshot, iteratively adjusting E_ES until all criteria are met, thereby establishing a valid and stable initial scenario snapshot.

Step 3: System Model Equivalence. To manage the computational complexity for the subsequent annual simulation, a static network equivalence is performed on the validated snapshot from Step 2. The equivalence criterion retains only elements at 500 kV and above. This reduces the full system model with over 16,000 buses to a computationally tractable equivalent model comprising 619 buses, 7 UHVDC lines, 74 synchronous generators, and 2 photovoltaic units.

Step 4: Annual Scenario-Sequential Data Generation. Based on historical or typical data, generate scenario-sequential data for renewable sources and load for a full year. Update the data E_ES and form a sequence of 8760 (365 days × 24 h) hourly snapshots.

Step 5: Annual Scenario-Sequential Simulation. This step involves solving a three-level sequential optimization problem for each of the 8760 hourly snapshots: first Unit Commitment (UC), then Active Power Dispatch (APD) based on UC results, and finally Reactive Power Dispatch (RPD) based on APD results. The process generates an economically optimal annual schedule that satisfies basic operational constraints, and the resulting schedules are written back to update the data E_ES.

Step 6: Annual Static N-1 Security Verification. Perform a steady-state N-1 security assessment on all 8760 snapshots using the updated data E_ES. This verifies the system’s stability against the contingency of any single branch outage.

Step 7: Scenarios State Adjustment under N-1 Constraints. For any hourly snapshots that fail the N-1 security verification, an automated state adjustment is triggered. This process constructs and solves an optimization problem that incorporates the N-1 security constraints, using the existing RPD results as an initial point. The resulting adjusted schedules are then written back to update the corresponding data in E_ES. Finally, the adjusted snapshots undergo a renewed N-1 security verification to ensure compliance, completing the corrective loop.

Figure 11 visualizes the final annual schedule, the output of the Scenario-Sequential Simulation and Scenarios State Adjustment, showing the 8760 sequential device states (e.g., active power and voltage setpoints for generators, reactive power from SVG devices, and bus voltages) that satisfy security constraints.

Figure 12 presents a specific N-1 contingency analysis case from the final N-1 security verification step. It demonstrates that for this contingency, all corresponding power flow solutions across the 8760 snapshots remain stable, with voltages within 0.9–1.1 p.u. and line loading rates within acceptable limits, thereby validating the static security of the final plan.

To evaluate the computational efficiency of BOS, we executed the steady-state planning and security validation workflow from Section 4.1 on a server cluster and recorded its time consumption. The cluster consists of two physical servers: (1) Server 1: CentOS 7, featuring two AMD EPYC 7763 CPUs (256 logical cores), 756 GB of DDR4 memory; (2) Server 2: CentOS 7, featuring two Intel Xeon Gold 5118 CPUs (24 logical cores), 256 GB of DDR4 memory.

The workflow’s primary computational load comes from the scenario-sequential simulation, the static N-1 security verification, and scenario state adjustment. The corresponding services decompose these requests into multiple tasks as follows:

The performance results are summarized in Table 6. These data represent the average of ten independent runs, with the total execution time varying within a ±5% margin. The Mean Measured Task Time is the average execution time recorded for each task.

To substantiate the utility of TCCSP, two critical comparisons are made. First, as a baseline comparison, a conventional implementation without TCCSP was attempted. This implementation failed to complete the workflow, as the system ran out of memory shortly after entering the stage of Scenarios State Adjustment under N-1 Constraints. Second, to quantify the efficiency gain of parallel scheduling, we estimate the serial execution time by multiplying the Mean Measured Task Time by the Number of Tasks for each stage. Compared to this estimated serial execution time, the TCCSP-managed workflow achieves an overall speedup ratio of nearly 100, completing the entire complex workflow in approximately 15.2 h. A detailed breakdown shows that the cumulative time spent on data read/write operations throughout the workflow was only about 1 h, accounting for less than 10% of the total runtime. This low overhead directly validates the efficacy of DRWOP in minimizing data access latency.

Furthermore, the high resource utilization during execution provides direct evidence of scheduling efficiency. As shown in Figure 13, CPU and memory utilization on both servers were sustained above 90% throughout the execution, demonstrating effective resource exploitation. Collectively, these results prove that BOS’s unified scheduling mechanism can efficiently manage and execute large-scale power system analysis, even when faced with millions of tasks, thereby meeting the demanding computational timeliness requirements of production practice.

The PLUMP provides the business platform with robust capabilities for integrating custom programs. This section mainly illustrates the process, via the user interface, through which users define and integrate custom models and algorithms.

Figure 14 shows the dynamic model design interface. This interface provides a LaTeX-based equation editor, allowing users to define dynamic mathematical models for devices. Then, the platform automatically parses all variables from the equations. Users can further specify the type of each variable (parameter, input, output, or internal) and generate standardized programs for a specific time-domain simulation engine (e.g., a self-developed engine such as PSAGo (short for Power System Analysis in Golang) or commercial tools like DSP [26] or PSCAD). For integration with the self-developed engine, each model programs must provide functions that support the iterative solution of its Differential-Algebraic Equations (DAEs). Taking the implicit trapezoidal integration rule coupled with the Newton-Raphson method as a concrete example, a compliant model is required to implement the following four standardized function interfaces:

For third-party engines that support user-defined models, the platform automatically converts the standardized model into code compliant with the target engine’s proprietary syntax. For engines lacking native user-defined model functionality, BOS generates a specific data adapter that maps the custom model and its parameters to the engine’s closest built-in model based on user-configured mapping rules. After code generation, users can directly navigate to an online testing environment to validate the correctness of the model’s dynamic characteristics within relevant projects and scenarios, forming a closed loop from design to verification.

Figure 15 shows the model’s overview interface. This interface visually displays all models managed by BOS through program indexed organization, including both official and custom models. As of the case study implementation, the platform has successfully integrated 64 custom models through this approach, covering synchronous generator sets (including the generator, excitation system, and automatic voltage regulator (AVR), prime mover and governor, power system stabilizer (PSS)), photovoltaic systems, wind power systems, battery storage systems, static var generators (SVG), and other types of devices. This fully demonstrates the effectiveness and universality of BOS in supporting agile model expansion.

Figure 16 shows the interface for algorithm development. Similar to model design, users can customize algorithm programs for business service slots and configure their parameter definitions through this interface. BOS automatically encapsulates them into callable components compliant with standardized program definitions and integrates them into the custom program repository.

Figure 17 shows the algorithm overview interface. It centrally manages all available algorithms, demonstrating seamless integration from algorithm development to deployment and invocation. As of the case study implementation, the platform has successfully integrated 61 custom algorithms through this approach, covering business such as power flow calculation, time-domain simulation, unit maintenance scheduling, unit commitment, active power flow generation, reactive power flow generation, indicator-based system assessment, system equivalence, etc.

The above workflow demonstrates that BOS has successfully decoupled program integration from traditional software development processes, transforming it into a standardized business activity led by domain experts. This not only significantly accelerates the iteration speed of business innovation but also endows the platform with endogenous momentum for continuous evolution.

This paper addresses the core challenges of business digitization in the new power system by proposing the domain-specific cloud Business Operating System with three systematic approaches—standardized definition, indexed organization, and dynamic management—applied to four core objects, Containers, Tasks, Programs, and Data. These approaches are materialized through five key technologies:

Case studies conducted on a real-world regional power grid validate the feasibility and effectiveness of BOS. Empirical results demonstrate that the BOS-based platform can effectively achieve seamless data connectivity across multiple business services, efficiently complete complex computational tasks, and support the integration of massive specialized models and algorithms. To advance BOS towards broader production adoption, future work will focus on:

DeepSeek V3.1 and V3.2 were used only for language refinement and not for content generation.

The authors would like to thank all those who provided support and constructive feedback during the preparation of this work.

Conceptualization, J.Z.; Methodology, J.Z. and J.H.; Software, J.Z., Y.L. (Yijian Luo), S.T. and J.H.; Validation, J.H., W.Y., Y.L. (Yang Liu), Z.L., Y.P. and Z.H.; Formal Analysis, J.H.; Investigation, J.H.; Resources, J.Z.; Data Curation, Y.L. (Yijian Luo) and S.T.; Writing—Original Draft Preparation, J.Z. and J.H.; Writing—Review & Editing, J.Z. and J.H.; Visualization, Y.L. (Yijian Luo); Supervision, J.Z.; Project Administration, J.Z.; Funding Acquisition, J.Z.

Not applicable.

Not applicable.

Due to BOS is not open-source, the study’s supporting data are only accessible to authorized South China University of Technology users via the platform through internal network access.

This work was supported in part by the National Natural Science Foundation of China (No. 52277101) and in part by the Fundamental Research Funds for the Central Universities (No. 2024ZYGXZR109).

The authors declare that they have no known competing financial interests or personal relationships that could have appeared to influence the work reported in this paper.