A Real-Time Formal Framework based on Service- Oriented approach implementing Interoperability and...

Doctorate Student; Emilia Doctorate Student; Emilia ColoneseColonese

Advisor; José M. Parente Advisor; José M. Parente de Oliveira de Oliveira

Pre-QualifyingPre-Qualifying

A Real-Time Framework based on Service-Oriented approach implementing Interoperability and System RequirementsA Real-Time Framework based on Service-Oriented approach implementing Interoperability and System Requirements Traceability Traceability 22

AgendaAgenda

IntroductionIntroduction

Real-Time Framework - RTFReal-Time Framework - RTF

Applying Formal MethodsApplying Formal Methods

Case Study – Formal RTF Adoption Case Study – Formal RTF Adoption

ConclusionConclusion




Misunderstand the requirementsMisunderstand the requirements

Underestimate complexity of the requirementsUnderestimate complexity of the requirements

Underestimate interface and interoperability requirementsUnderestimate interface and interoperability requirements

Assume the marketplace has what is needed to meet Assume the marketplace has what is needed to meet stringent capabilitiesstringent capabilities

Assume commercial off-the-shelf equipment or software Assume commercial off-the-shelf equipment or software will need no modifications or enhancements will need no modifications or enhancements

Being out of your core competency Being out of your core competency

Why software problems and challenges are hard to be recognized? Why software problems and challenges are hard to be recognized?


Timeliness

Ev1Ev2 Ev3

Responsiveness

T. 1

T. 2

Concurrency

Dynamic Structure

Reliability

Real Time SystemsDomain: Main

Characteristics

Distribution



Real-Time applications have specific challenges of Real-Time applications have specific challenges of

performance in order to deliver valid information to the performance in order to deliver valid information to the

decision makers in near real-time. System interoperability decision makers in near real-time. System interoperability

failure happens because it is not addressed early in the failure happens because it is not addressed early in the

system design process nor supported throughout the system design process nor supported throughout the

operational life of a Real-Time System. Also, the existing GAP operational life of a Real-Time System. Also, the existing GAP

of translating and tracking functional requirements to the of translating and tracking functional requirements to the

software design and the inexistence of formal methods software design and the inexistence of formal methods

prevents the traceability of the requirements to be realized and prevents the traceability of the requirements to be realized and

the correct system development process respectively.the correct system development process respectively.

ProblemProblem



This research proposes a formal framework that have a This research proposes a formal framework that have a

built-in interoperability design, requirements translation to built-in interoperability design, requirements translation to

the logical model with traceability allowing to collect the logical model with traceability allowing to collect

information of each realized requirement at run-time, a information of each realized requirement at run-time, a

formalistic applied to the logical view, and a new formalistic applied to the logical view, and a new

approach of service-oriented with self-adaptive behavior approach of service-oriented with self-adaptive behavior

at runtime, in order to optimize the overall system at runtime, in order to optimize the overall system

performance.performance.

Proposed SolutionProposed Solution



Dynamic and real-time approach to the service-oriented Dynamic and real-time approach to the service-oriented architecture allowing “plugging-in” and “plugging-out” architecture allowing “plugging-in” and “plugging-out” services required at run-time; services required at run-time;

Built-in interoperability mechanism aiming to achieve a Built-in interoperability mechanism aiming to achieve a transparent data exchange among systems, subsystems, transparent data exchange among systems, subsystems, and components excluding unnecessary gateways; and components excluding unnecessary gateways;

Capability of tracking each system requirement through Capability of tracking each system requirement through use case realizations (scenarios); and use case realizations (scenarios); and

Formal methods applied in the logical view to improve the Formal methods applied in the logical view to improve the correctness of the model and consequently the code.correctness of the model and consequently the code.

The framework is based on the following key M&D:The framework is based on the following key M&D:



LogicalView

ScenarioView

RealWorld

Service A

Service C

Service B

Service G

Service F

Service EService D

Service H

Service I

Service K

Service J Service M

Service OService L

Service N

UseCase4 UseCase8UseCase6UseCase5

UseCase7

UseCase1

UseCase9

UseCase3

UseCase2

Activity 9Activity 2Activity 1

Activity 3

Activity 5

Activity 7

Activity 4

Activity 6 Activity 8

EventsDriveUse

Cases

EventsDriveUse

Cases

Use CasesDrive

Services

Use CasesDrive

Services

In a Self-Adaptive Real-Time Services-Oriented environmentEvents drive Use CasesEvents drive Use Cases and Use Cases drive ServicesUse Cases drive Services

Effectively coupling activities data exchange, only to needed Services and not to Systems.

Self-Adaptive Real-Time Services-OrientedSelf-Adaptive Real-Time Services-Oriented



AgendaAgenda








Framework Modeling:Framework Modeling: Requirements (Use Cases) Dynamics (Self-Adaptive) Common Protocol (Data

Interoperability) System Controller (Dynamic

Service Broker) Services & Invokers

(Interoperability Design Pattern)

Real-Time FrameworkReal-Time Framework

OperationalView

OperationalView

InfrastructureView

InfrastructureView

SystemView

SystemView

SystemEngineering

Process

SystemEngineering

Process

Non-functional RequirementsSystem Specifications

System Requirements

Functional RequirementsSystem Specifications

Architecture Attributes:• Service-Oriented approach• Self-Adaptive• Interoperability• Design Patterns• Requirements Traceability• Formal Methods • Real-Time execution

Implementation:• MDD & MDA• UML-RT• RT I-CASE Tool & UP• Code generation• Verification/Test


Real-Time Framework – ImplementationReal-Time Framework – Implementation

MDD & MDAMDD & MDA

Figures Source:http://www.omg.org/mda/

MDA

Model-Driven Development represents a number of styles to develop software by using models.

Model-Driven Architecture was proposed by OMG.


Applying MDD: UML-RTApplying MDD: UML-RT

UML Structural and Behavioral Diagrams extended for Real-Time (UML-RT)

Collaboration Deployment

Use Case Sequence ActivityStates

ComponentsClass



Computation Independent Model -

CIM

Platform Independent Model - PIM

Platform Specific Model - PSM

Platform Model - PM

Transformation Model - TM

Applying MDD to Real-Time Systems leads us to think not only on the problem, but in the whole solution process.

MDAMDA

Applying MDD: MDAApplying MDD: MDA



Notation, Modeling and ToolNotation, Modeling and Tool

Rational Rose Real-Time (RRRT) CASE Tool is based on the Unified Process (UP) and UML-RT notation enabling

the system development to use MDA and MDD.



Code Generation & TestCode Generation & Test



Real-Time Framework - ArchitectureReal-Time Framework - Architecture

Service-Oriented Architecture (SOA)Service-Oriented Architecture (SOA)

SOA common principles: services share a formal contract, are reusable, loosely coupled, composable, autonomous,

stateless, discoverable, and have an abstract underlying logic.


Service-Oriented Approach for RTFService-Oriented Approach for RTF


RT-SOA common principles: services share a formal contract, share formal classes, are reusable, loosely

coupled, composable, autonomous, minimized statefull, dynamically activated and deactivated depending on the requestor, and have an abstract underlying logic.


Self-Adaptive Approach Self-Adaptive Approach





InteroperabilityInteroperability


The framework addresses the interoperability built-in a standard interface into the system design.


Design PatternsDesign Patterns




The interoperability mechanism inserts a formal contract and

classes into the requestor system

design.


Requirements TraceabilityRequirements Traceability





Formal MethodsFormal Methods





Framework Components (Active Classes):

External_Invoker Capsule; Internal_Invoker Capsule(s); SystemStarter Capsule; SystemController Capsule with Dynamic Server Capsule(s) built in; and the

ControlledSystem.

Real-Time Framework - ModelingReal-Time Framework - Modeling

Framework StructureFramework Structure DiagramDiagram


Control Station FrameworkControl Station Framework

SystemController Structure Diagram


ServiceServers


Self-adaptive policy is defined by a kind of Event-Condition-Action (ECA) rules:

The Event is received as a message and is already related to some use case;The Condition specifies what service needs to be activated based on the content of the received message; and The Action is the activation of the correct Service.

Control Station FrameworkControl Station Framework


This dynamic behavior of activating and deactivating services is controlled by This dynamic behavior of activating and deactivating services is controlled by the the SystemControllerSystemController State Model. State Model.


Internal or External InvokerInternal or External Invoker

Design Pattern applied to the Basic Invoker Statechart

Rules applied in each state



Service ServerService Server

Design Pattern applied to the Basic Server Statechart

Rules applied in each state



Common Protocol ClassCommon Protocol Class

The format design for data interchange. The CommonProtocol Class promotes the interoperability, has all information to identify the invoker, the service, the message type, the use

case, timestamp, priority, data, altitude, latitude, and longitude.



CommonProtocol Class AssociationsCommonProtocol Class Associations



Component ClassComponent Class

Actors related to the software are identified at the design phase. The authors defined a passive class named Component Class to

register all actors that can communicates with the software during the system execution.


Message ClassMessage Class

Instead of creating several signals to be received and transmitted through the communication ports of systems, subsystems or

components, the authors defined a passive class named Message Class to register type of signal that will compose the software

needs of communication during the system execution.

This design approach for message types generates just one port of communication avoiding unnecessary gateways.


UseCase ClassUseCase Class

Functional requirements are mapped to the software at the design phase to use cases. The authors defined a passive class named UseCase Class to register all use cases that are designed to be

realized during the system execution.

Further work in this research will implement the RealizedUseCase Class to store information for each use case realized. Those information might be used

to extract knowledge to help decision makers to accomplish their tasks.



AgendaAgenda









Real-Time FrameworkReal-Time FrameworkSystemController Structure Diagram

ServiceDistribuition Structure Diagram

ServiceDistribuition State Diagram


Minimization ApproachMinimization Approach

Step 1 - Create a language for the Finite Deterministic Automata Step 1 - Create a language for the Finite Deterministic Automata (FDA) to represent the trigger events of the state machine.(FDA) to represent the trigger events of the state machine.

Step 2 - Represent the target state diagram as a FDA giving or Step 2 - Represent the target state diagram as a FDA giving or not the same name of the state.not the same name of the state.

Step 3 - Apply the Myhill-Nerode Minimization algorithm.Step 3 - Apply the Myhill-Nerode Minimization algorithm.




Create a language for the FDA to represent the trigger Create a language for the FDA to represent the trigger eventsevents

3sig_cl_out

2sig_sr_out

1

Ttimeout

FDA LanguageTrigger event

send



Represent the state diagram as a FDARepresent the state diagram as a FDA

A = {Q, ∑, б, q0, F} where Q is the states of automata A, ∑ is the alphabet, б is the transition function, q0 is the initial state and F is the Final state.

3sig_cl_out

2sig_sr_out

1

Ttimeout

FDA LanguageTrigger event

send


Apply the Myhill-Nerode Minimization algorithmApply the Myhill-Nerode Minimization algorithm




Results expected after the Minimization application Results expected after the Minimization application

Reduction of the logical model and code complexity Improvement of development time Lower risk of failure Better performance

1. The minimization promoted the reduction of the case study automata from 4 states and 6 transitions to one state and 2 transitions.

2. The reduction percentage was 50% in state numbers and 64% in transition numbers decreasing the logical model complexity in 57%.

3. The code size was reduced in 30%.

Results verified after the Minimization application Results verified after the Minimization application


AgendaAgenda






Case Study – Formal RTF AdoptionCase Study – Formal RTF Adoption



Implementation of a real-time system prototype to operate Unmanned Air Vehicles (UAV) from a Control Station (CS)


Prototype Structure Diagram

The prototype control surveillance mission to a UAV. An Internal_Invoker ( EVIG_Invoker) was designed to invoke the

Surveillance Server (EVIG), in order to send a mission to the UAV. The CS with five Service Servers and the system to be controlled : UAV. Nor

External_Invoker neither SystemStater are used in this scope.

Scope LimitationScope Limitation



Steps needed to successfully reuse the framework:

Step 1 - Adopting of the Communication Protocol Class;

Step 2 - Updating the Use Case Class, by inserting appropriate system’s use cases;

Step 3 - Adjusting the systems and subsystems to the framework; and

Step 4 - Adjusting the state which communicates to the CS applying the interoperability pattern.



1- Adopting of the Communication Protocol Class


Adopted for:EVIG_Invoker; CS; and UAV

2- Updating the Use Case Class, by inserting appropriate system’s use cases

Adopted for:EVIG_Invoker; CS; and UAV


3 - Adjusting the CS system structure to the framework

CS Structure Diagram



EVIG_Invoker Structure Diagram

3 - Adjusting the EVIG_Invoker system structure to the framework



UAV Structure Diagram


3 - Adjusting the UAV system structure to the framework


4 - Applying the interoperability pattern to the EVIG_Invoker.

EVIG_Invoker State Diagram



4 - Applying the interoperability pattern to the EVIG Service Server. In this example we show the code from the state that sends missions to the UAV.

EVIG Server State Diagram



4 - Applying the interoperability pattern to the subsystem Mission Decoder, part of the UAV system structure

This subsystem is responsible to connect the CS in order to receive mission and send the results.

Mission Decoder State Diagram



Case Study - Case Study - Testing the systemTesting the system


AgendaAgenda





ConclusionConclusion ConclusionConclusion



The implementation of a real-time formal framework using the RT-SOA approach was successful.

The self-adaptive mechanism in the framework did not increase the design complexity. Instead, it has allowed a simple solution determination at run-time to the system structure in a given scenario.

The creation of a design pattern for interoperability defined a formal semantic for message exchange.

Easy integration of Invoker Components to the target system by applying the interoperability pattern.

Unique approach in the sense of modeling and tracking functional requirements through system deployment, and applying formal methods to minimize states to improve the system correctness.

Major findings: a solution for some gaps of tracking the correct deployment Major findings: a solution for some gaps of tracking the correct deployment of use cases, the creation of the interoperability pattern, introducing a of use cases, the creation of the interoperability pattern, introducing a formal method in the logical view, and the adaptation of the SOA to be used formal method in the logical view, and the adaptation of the SOA to be used on RTS.on RTS.

Thank you!Thank you!Obrigada!Obrigada!

“Eu sou o caminho, a verdade e a vida. Ninguém vem ao Pai, a não

ser por mim.”João 14:6

“Se me pedires alguma coisa em meu nome, eu o farei.”

João 14:14

A Real-Time Formal Framework based on Service- Oriented approach implementing Interoperability and...

Documents

Transcript of A Real-Time Formal Framework based on Service- Oriented approach implementing Interoperability and...