Partition Software Application

Step 2 of 6 in Migration to Service-Oriented Architecture Using Model-Based Design

• 1
• 2
• 3

Identifying the optimal partitioning of a signal-based model into a modular set of services is an iterative and exploratory process. This process involves continuously analyzing and refining the boundaries and interactions of the services to ensure they align with both functional and nonfunctional requirements.

When partitioning a signal-based model:

• Determine functional boundaries for each service.

• Evaluate scalability requirements.

• Consider the development workflow and create services that align with the team structure.

• Consider the execution event types and the corresponding interface types to determine how each component will manage its data and how data will be synchronized across components.

  Event Type	Description	Communication Type	Interface	Simulink Implementation
  System	The middleware automatically starts certain events at specific times set by the application.	Software component to software component (SWC˂—˃SWC)	Sender-receiver (S/R) interface	Outport block (Sender) Inport block (Receiver)
  Communication	The middleware triggers events when the application communicates directly between a sender and receiver or between a client and server.	Software component to software component (SWC˂—˃SWC)	Sender-receiver (S/R) interface	Outport block (Sender) Inport block (Receiver)
  		Software component to system service (SWC —˃ System Service)	Client-server (C/S) interface	Function Caller block (Client) Function Subsystem (Server)
  Synchronization	The middleware triggers events to make sure a function runs in sync with an event happening internally or externally of the system.	Software component to software component (SWC˂—˃SWC)	Sender-receiver (S/R) interface	Outport block (Sender) Inport block (Receiver)

Main Application and Service Components

For this example, the signal-based model is partitioned so that the main application software component retains full functionality and the supporting functions are refactored into service components. The refactored model at the end of the example calls out to services in place of some of the inline functionality using a client-server interface.

Note

This example uses only client-server communication. Real-world applications typically combine client-server and sender-receiver communications, using the appropriate method for the abstraction level of the problem. Using only client-server communication can add complexity.

The main application generates the brake and torque commands, while the supporting functions contained in these subsystems are refactored into service components:

• Acceleration pedal position to wheel torque request

• Brake pedal position to total braking pressure request

• Power limit calculations

• State-of-charge calculation

• Drive mode detection

• Battery state request

• Torque vectoring calculation

To open the signal-based model, run this command.

open("EvPwrCntrllrEM.slx");

This diagram highlights the software for the main application using an orange box and highlights the software for the service components using blue boxes.

The next step, Create Architecture Model and Service Interface, models the software architecture based on the partition of the signal-based model determined in this step.