Master Thesis in Intelligent Embedded Systems
15Credit advanced level
Automated Orchestra for
Industrial Automation
On
Virtualized Multicore Environment
ii
ABSTRACT
Industrial control systems are applied in many areas e.g., motion control for industrial robotics, process control of large plants such as in the area of oil and gas, and in large national power grids. Since the last decade with advancement and adoption of virtualization and multicore technology (e.g., Virtual Monitoring Machine, cloud computing, server virtualization, application virtualization), IT systems, automation industries have benefited from low investment, effective system management and high service availability. However, virtualization and multicore technologies have posed a serious challenge to real-time systems, which is violating timeliness and predictability of real-time application running on control systems. To address the challenge, we have extended a real-time component-based framework with virtual nodes; and evaluated the framework in the context of virtualized multicore environment. The evaluation is demonstrated by modeling and implementing an orchestra application with QoS for CPU, memory and network bandwidth. The orchestra application is a real-time and distributed application deployed on virtualized multicore PCs connected with speakers. The result shows undistorted orchestra performance played through speakers connected to physical computer nodes. The contribution of the thesis can be considered: 1) extending a real-time component-based framework, Future Automation Software Architecture (FASA) with virtual nodes using Virtual Computation Resource (VCR) and 2) design and installation of reusable test environment for development, debugging and testing of real-time application on a network of virtualized multicore environment.
Date: 13 September 2013
Carried out at: ABB Corporate Research, Västerås Advisor at MDH: Moris Behnam
Advisor at ABB Corporate Research: Kristian Sandström Examiner: Thomas Nolte
iii
Acknowledgement
I would like to thank my supervisor Kristian Sandström and examiner professor Thomas Nolte for giving me this interesting thesis opportunity. I would like to appreciate Kristian Sandström once more and Aneta Vulgarakis for their invaluable guidance and assistance during my thesis work. Veronika, I admire your willingness to help me solve technical problems.
Furthermore, I would like to express my deep gratitude to my supervisor Moris Behnam for his encouragement and loving approach; and also taking the time to read my report. Special thanks to my examiner Thomas Nolte for understanding my enthusiasm to do the work and recommend me to this position. I would like to thank my family for cherishing me moral support. Finally, thank you to ABB and colleagues – it was fun and exciting!
iv
NOMENCLATURE
Abbreviation
ICS Industrial Control System
FASA Future Automation Software Architecture DCS Distributed Control Systems
RTOS Real-Time Operating System VCR Virtual Computational Resource VCPU Virtual CPU
VMM Virtual Machine Monitor
IEC International Electrotechnical Commission HVM Hardware-assisted Virtual Machine
PV ParaVirtualization
Dom0 Domain 0 – to show guest machine runs at privilege mode (ring 0) DomU Domain U – to show guest machine runs at unprivileged mode SDN Software-defined Networking
SDLC Software Development Life Cycle
IOMMU Input/Output Memory Management Unit PVHVM ParaVirtualized HVM
PVOPS ParaVirualized Options (paravirt-ops)
4DIAC Framework for Distributed Industrial Automation and Control BVT Borrowed Virtual Time
BW Bandwidth
pCPU Physical CPU vCPU Virtual CPU
SEDF Simple Earlier Deadline First VNC Virtual Network Computing
SPICE Simple Protocol for Independent Computing Environment PECOS PErvasive Component Systems
VIF Virtual InterFace
TCF Target Communication Framework SSH Secure Shell
v CONTENTS Chapter 1 INTRODUCTION 7 1.1 Introduction ... 7 1.2 Related work ... 8 1.3 Problem formulation ... 9
1.4 The contribution of the thesis is two folds ... 10
Extending FASA real-time component-based framework to virtual nodes ... 10
Design Reusable Test Environment ... 10
1.5 Analysis of the problem ... 11
Setting up of Virtualized Multicore Environment ... 11
Development of Automated Orchestra Application ... 12
Chapter 2 BACKGROUND 14 2.1 Theoretical Background ... 14
Component-Based Real-time Software Development (CBSD) ... 14
Future Automation Software Architecture (FASA) ... 15
Virtualization ... 17
2.2 Technological Background ... 18
Xen Hypervisor (Xen pronounced /’zɛn/) ... 18
Open vSwitch ... 19
4DIAC-IDE ... 20
Chapter 3 Development of Orchestra components 21 3.1 Component development mechanism ... 21
3.2 Orchestra organization ... 22
3.3 Define requirements ... 22
3.4 Distributed orchestra application overview ... 25
3.5 Component modelling ... 26
3.6 Template generated by 4diac-fasa plug-in ... 27
Application directory ... 27
Library directory ... 27
Module directory... 28
3.7 Standard Midi file format and partitioning ... 28
Standard MIDI file format ... 28
Software tools and libraries ... 29
Midi file partitioning and rhythm message ... 30
3.8 Algorithm Implementation for functional blocks ... 31
Conductor Functional Blocks implementation... 31
Principal Functional Block implementation ... 31
Musician Functional Block implementation ... 32
Chapter 4 Deployment of Orchestra Application 33 4.1 Setting up - Network of Virtualized Multicore environment ... 33
Host installation: Ubuntu-12.04 LTS ... 33
Xen hypervisor installation ... 34
Open vSwitch installation ... 34
VM installation: yocto VM, Ubuntu-12.04 LTS headless ... 34
4.2 Define Virtual computation resource ... 36
VCR with QoS for CPU, memory and network BW ... 36
vi
4.3 Orchestra Application Management ... 39
FASA component manager ... 39
Libvirt and Virt-manager ... 39
Orchestra distribute management script ... 39
Chapter 5 CONCLUSION 40 5.1 Result ... 40
5.2 Future work ... 41
Extending orchestra application and development... 41
Defining virtual computational resource ... 41
Chapter 6 REFERENCES 42 Chapter 7 Appendix 1 A. Orchestra modeling using 4DIAC ...1
B. Orchestra component resource allocation on a single host and scheduling ... 4
C. Orchestra component resource allocation on a network level and scheduling .. 5
D. Virtual machine configuration xen hyprevisor ... 7
E. HP Compaque Elite 8300 Ultra-slim Desktop summary ... 8
F. Open vSwitch throughput test result using iperf tool...1
7
Chapter 1
INTRODUCTION
1.1 Introduction
Industrial control systems (ICS) are found in many areas, e.g., in motion control for industrial robotics, process control of large plants such as in the area of oil and gas, and in large national power grids. A control system controls processes using control application by interacting with environment through sensors and actuators. ICS are becoming large and complex now days due to many reasons. For instance, Distributed Control Systems, DCS such as ABB 800xA automation provides extended services beyond controlling simple industrial processes, such as energy efficiency and asset management, energy savings and operator effectiveness [1]. Likewise, embedded control systems are imposed with more regulatory requirements than before for safety reasons (such as IEC 61508, ISO 26262) and other sub segment standards in energy, process automation and control. As a result, it is common and desirable for a single industrial control system to execute more than one application simultaneously to preserve physical space and ease of management.
To meet current industry demands for large and complex software systems, integration of software technologies and consolidation of hardware and software is crucial; for example adoption of virtualization and multicore technology. Virtualization powered by hypervisors such VMware ESX and Xen provides the ability to run multiple virtual machines in a single physical node by abstracting underlying hardware resources such as CPU, memory and communication systems; hence, low hardware investment and high energy cost savings. Even service availability and maintenance become easier due to compartment of virtual machines efficiently on a single physical node. Similarly, multicore technology is benefiting general computer industry at large and now a day being applied to industrial and embedded systems such as in mobile systems. Multicore processors have multiple cores in a single chip; therefore, it enables multiple applications to run parallel in each core without the need for separate hardware systems while maintaining application integrity as compared to unicore systems. Moreover consolidation of virtualization and multicore technology can provide spatial and temporal isolation of applications running in a single machine.
8
For example in Figure 1, multiple virtual machines are running on top of multicore platform which is virtualized using Xen hypervisor. The hypervisor allocates one-to-one mapping of cores to virtual machines to achieve high degree of temporal and spatial isolation of applications running on each virtual machines.
The benefit of virtualization and multicore technology is a trade-off with challenges they incur in real-time systems. Due to complexity of multicore architecture, e.g., shared bus, shared memory and multi-threading, porting of real-time application across different hardware platforms has been challenging. Likewise in virtualization technology, hypervisor schedulers such as Xen credit scheduler incur significant over head for example as compared to traditional real-time schedulers. And this introduces jitter to virtual machine execution which leads to unpredictable real-time application execution. Real-time component-based platforms such as FASA [2], CAmkEs [3], PECOS [4] provide development and runtime environment for real-time component-based application. And the purpose of the thesis is to evaluate real-time component-based framework, FASA in the context of virtualized multicore environment. And this will be demonstrated using an automated orchestra application. The orchestra application is a real-time and distributed application developed using real-time component based software development platform. Finally, the application is expected to produce acoustically pleasant orchestra (unnoticeable delay and latency) through speakers connected to each physical computer node.
The rest of the report is organized in the following way. Chapter 1 is Introduction and will continue to analyze the thesis problems in depth. Chapter 2 is Background to theoretical and technological aspect of real-time component based software development, virtualization and software technologies used in the thesis scope of work. Chapter 3 is development of orchestra application; and chapter 4, deployment of orchestra application on network of virtualized multicore PCs. Finally, chapter 5, result, conclusion and future work is discussed.
1.2 Related work
In this thesis work, using orchestra to evaluate real time system is motivated by Julien et al. [5]. Among others they used orchestra to show synchronization and integration of several IEC 61499 standard compliant functional blocks on a network of NetBurner MOD5272-100CR systems. They were able to show how the orchestra was played without distortion using functional blocks showing applicability of IEC 61499 standard for soft real-time application. In this thesis research, however, we will use similar automated orchestra application on virtual and multicore environment. In addition, we will evaluate a real-time component framework as compared to FORTE or similar runtime environment used in the above mentioned research.
There have been many attempts to make Xen hypervisor applicable for real-time application, such as in the case of RT-Xen [6] [7]. RT-Xen implements four server based hierarchical scheduling algorithms (periodic, polling, sporadic and Deferrable server) which are based on fixed-priority preemptive scheduling. The algorithms were evaluated and compared to Xen default Credit scheduler for overhead measurements (latency and context-switches) over 10 seconds of execution; and the result showed an average of 0.2% time loss for RT-Xen schedulers and 0.04% for Xen Credit scheduler. To minimize overhead of Xen scheduler, we avoided using RT-Xen; instead, we mapped each virtual machine (aka domains) to a single core so that excepting credit scheduler from load balancing VCPU across physical cores, therefore, increasing timeliness and predictability of component execution on domains.
9
Little work is done, at least to my knowledge, on evaluation of timeliness and predictability of real-time component-based framework on virtual environments. Evaluations of several component technologies for embedded system can be found in Anders Möller et al. [8]. They used technical and development process requirements to prioritize component technologies. Among which PECOS was found to perform better in average; especially for resource constrained application. In this approach; however, only technical evaluation of timeliness and predictability of FASA component model framework will be performed for real-time and distributed application.
1.3 Problem formulation
The purpose of the thesis is to extend real-time component-based framework, Future Automation Software Architecture, FASA with virtual nodes using Virtual Computational Resource (VCR); and evaluate timeliness and predictability f real-time application in the context of virtualized multicore network of PCs. And this is demonstrated by modeling and implementing orchestra application. The application is soft real-time1 system and distributed
application which implements functionality and synchronization of orchestra performance. The thesis work will try to address the following research sub-problem:
Problem #1: Study and implement the concept of Virtual Computational Resource,
VCR2 with QoS for CPU, memory and network bandwidth.
Underplaying computer hardware resources such as memory, CPU and network bandwidth is divided into a set of virtual resources defined in textual format, identified in this report as Virtual Computational Resource, which enables a virtual system to run in a host system. Virtual Computational Resource creates a layer of abstraction to hardware resources which makes it possible to preserve execution behavior of virtual systems across differ hardware platforms. The benefit of VCR can easily be seen in porting real time application from for instance from unicore to multicore system.
Problem#2: Model and implement an orchestra application on a network of virtualized multicore PCs.
According to a research made by Nelson Posse et al. [9], human ear is capable of recognizing latency between 20-30 milliseconds. This implies, events occurring within 20-30 milliseconds drift can be identified as separate events by our ear. Furthermore, the research discusses the power of human perception to musical rhythm can reach to 4ms precision. This leaves us how we can exploit our hearing and rhythm perception capability in real-time systems. Therefore, musical orchestra will be automated to demonstrate how real-time component-based frameworks perform under virtual computational resource.
Problem #3: Study to what degree the architecture will support software-independence by evaluating how different allocations of application parts impact real-time behavior.
Automated Orchestra application will be deployed in one and more physical nodes; and see how this different allocation will result in playing the orchestra properly with maintaining timeliness and predictability of real-time application.
Problem #4: Dynamic turn ON/OFF of instruments and prepare test configurations.
1 A real-time system if missed deadline degrades performance but still is usable afterwards; for
example, out of sync an instrument produces acoustically unpleasant music but still continues to play the orchestra.
2 VCR is a computational resource obtained by partitioning an actual hardware resource e.g.,
10 1.4 The contribution of the thesis is two folds
Extending FASA real-time component-based framework to virtual nodes
The real-time component-based framework under analysis, FASA, according to previous records does not support partitioning [2]. In this thesis work, it is extended to support virtual nodes using Virtual Computational Resource (VCR) with QoS for Memory, CPU and network bandwidth. VCR is a computing resource definition created by partitioning actual hardware resource into units that can individually be used for development, allocation, verification and analysis of parts of a system. For instance, FASA application parts, such as automated orchestra components would be allocated to VCRs; and the QoS defined in the VCR e.g., CPU, Memory and network bandwidth could be enforced during runtime by Virtual Machine Monitoring (VMM) such as Xen hypervisor.
VCR can be prepared separately without the knowledge of hardware system at hand; consequently, facilitating software engineering process e.g., requirement analysis and design. It also preserves timeliness and predictability of real-time application parts if migrated, for instance to a different hardware architecture than where it originally was running, e.g., from a unicore to multi-core system. Finally, the communication performance of the test environment as show in Figure 2 such as jitter, latency and throughput is compared over Ethernet protocol with and without VCR.
Design and Install Reusable Test Environment
The test environment is a network of computer nodes; and consists of two nodes virtualized using Xen hypervisor, two non-virtual nodes for benchmark purpose and a central management system. Three virtual nodes are created per host; and are connected using OpenvSwitch3 – an advanced virtual switch. The virtual nodes and nodes used for benchmark
are installed with Real-Time OS developed using Yocto Project Development4 approach – an open source and collaborative project which creates custom Linux distribution for embedded systems. Furthermore, the test environment is setup with Yocto Project Development for System Core developers (e.g., building OS) and Yocto Application Developers (application which run on top Yocto Machines). It provides a platform for further development, debugging, testing and evaluation of real-time OS and network communication performance.
It has central and coordinated management for computer nodes using technologies, e.g., Virtual Network Computing (VNC), Target Communication Framework (TCF), Secure Shell (SSH) and Libvirt - a library for managing platform virtualization technologies such as Xen hypervisor, KVM,VMWare ESX. The test environment would be suitable, e.g., to develop and cross-compile network performance tool for Yocto Machines, test high precision synchronization of virtual nodes and Xen hierarchical scheduler development.
3 OpenvSwitch - an open source virtual switch suitable virtualization. http://openvswitch.org/ 4 Yocto Project is an open source and collaboration project for creating Linux based distribution
for embedded systems. https://www.yoctoproject.org/
11 1.5 Analysis of the problem
We may breakdown the thesis work into two parts: Setting up of Virtualized Multicore Environment and Development of Automated Orchestra Application. Using this approach we will discuss how the above mentioned sub problems will be addressed throughout the thesis work
Setting up of Virtualized Multicore Environment
Linux OS (aka GNU/Linux)5 has become the choice of academic research in OS,
mainframes, supercomputers and now days being used in embedded systems, e.g., mobile phones, network routers, automation control. Android OS is a prominent example of Linux OS used in embedded systems; it is build from Linux Kernel and deployed on mobile phones. Linux OS is free and open source available in several distribution forms; example of commercial distributions includes Ubuntu (Canonical Ltd.), Fedora (Red Hat) and openSUSE (SUSE). Ubuntu is one of the most popular distributions in Linux community; and it uses Debian package manager, dpkg which is powerful and easy to use. We will use Ubuntu-12.04 as a host and management OS in setting up of virtualized multicore environment.
The following are a brief description how virtualized multicore environment will be established:
1. Host virtualization - A hypervisor will be used to monitor (or CPU access, memory usage and I/O peripheral access) virtual machines. The most common open source hypervisors at the time of writing the thesis are Xen, KVM and VirtualBox. Xen hypervisor is chosen for I/O performance and maturity reasons. It is supported by a number of companies such as Amazon, Cloud.com and GoGrid; and generally performs better as compared to KVM and VirtualBox according to some study6.
2. Virtual Machine - OS for virtual machine is based on Real-Time OS (RTOS) from Yocto Project Development7 – a lightweight, customized Linux distribution.
3. Communication and synchronization of virtual and non-virtual nodes - Once established the virtual environment; communication between virtual machines is achieved through virtual switch supporting OpenFlow standard. OpenFlow standard is an open standard which defines the control and forwarding layer of software defined networking, SDN8; similar functions found in routing and
switching. The most common open source virtual switch supporting openflow are open vSwitch and Indigo. Since open vSwitch hot-plug script9 is supported
by default in the latest release of xen-4.3, open vSwitch is used for implementation. Computer nodes are synchronized to central node through Network Time Protocol (NTP).
4. Tuning virtualization (CPU and Memory usage) - The following components of hypervisor if tuned and configured correctly give an optimal virtualization for execution of orchestra application.
Scheduler – Xen comes with default credit scheduler; and other schedulers SEDF and BVT. Virtual CPU, VCP is another feature to be considered for optimization. The more VCPU a guest machine has the
5 Linux OS: http://en.wikipedia.org/wiki/Linux 6 Xen Vs. KVM:
http://indico.cern.ch/getFile.py/access?contribId=5&resId=1&materialId=slides&confId=45282
7 Yocto project: https://www.yoctoproject.org/
8 SDN: http://en.wikipedia.org/wiki/Software-defined_networking
12
more CPU access has. In fact, to achieve predictability, Xen can be extended with other schedulers, e.g., addition of hierarchical real-time scheduler
I/O – Xen HVM hypervisor enables I/O device emulation and direct device access from virtual machines. High performance is achieved when configured with direct I/O access also called PCI pass-through in Xen.
Memory – Virtual machines should not suffer from limited memory access. Instead, virtual machines will be allocated sufficient memory during creation.
Once we have a working environment, we define a Virtual Computational Resource (VCR) will QoS for CPU, memory and network bandwidth for each virtual node.
Development of Automated Orchestra Application
First a preliminary study of orchestra will be conducted such as organizational structure, communication and synchronization of musicians. This is crucial to imitate relevant features required for our application. Following this, orchestra application will be developed based on approach suggested by de Almeida et al. [9] which emphasizes the need for componentization on design and implementation level through the Software Development Life Cycle, SDLC. Based on detail analysis of orchestra application, first will be to model and implement components required for the application. This will be followed by deployment of the application on virtualized multicore environment which involves resource allocation (CPU, memory, network bandwidth) and development of application schedule.
4DIAC-IDE and FASA are the platform to be used for development and runtime execution of orchestra application. FASA is an ABB in-house research framework for development of distributed control applications. It is used to develop, build and run cyclic application. Since there is close connection to development team of FASA for support, it is favoured over other platforms such as CAmkES and PECOS for this thesis work.
The following tools will be used to develop the orchestra application: 1. FreeMind - a mind mapping tool
2. 4DIAC-IDE – an open source component-based software development IDE based on IEC 61499 standards.
3. 4diac-fasa plug-in – a modelling transformation tool from 4IDAC to FASA components model.
4. FASA framework - a development and runtime execution platform for distributed control application.
Using the above listed tools, the orchestra components and distributed application will be developed following a software development life cycle process. First, a mind mapping tool,
FreeMind is used to describe the basic picture of orchestra organization that is the conductor,
principal and musician and the hierarchical relationship. Next a UML (use case and component diagram) tool, Umbrello is used for detail problem specification, component design and relationship. Finally, the design will be realized using 4DIAC-IDE tool to model and implement the prototype orchestra application.
13
Once the orchestra application is developed on the 4DIAC-IDE, a 4diac-fasa plug-in will be used to transform the model which was previously based on IEC 61499 standards to a FASA compatible component modelling platform for runtime execution. Since the 4DIAC-fasa plug-in transformation does not have support yet for resource allocation devices to components, FASA application template, which defines allocation of components, will be manually edited. In addition, to launch the application from a central node, a script will be developed for deploying, starting and stopping the application on the virtualized nodes.
14
Chapter 2
BACKGROUND
2.1 Theoretical Background
Component-Based Real-time Software Development (CBSD)
A component is a reusable unit of software deployment accessed through an interface10 [10]. Adopting a component based software development, especially for large and complex software architecture simplifies development, encourages inter operability of third party components. Since components are usually tested and maintained frequently, application developed using component based achieves higher quality and shorter development time task based applications. In fact, several industries have benefited from component-based development; for instance, the global industrial automation company, ABB has implemented component based in the new release of industrial automation and collaborative platform product, System 800xA Extended Automation.
Industrial Control Systems have strong constraint in resource utilization, especially on hardware resources (CPU, Memory, Network Bandwidth and Hard disk), power consumption, and physical space. On top of this, complexities of such applications are growing from time to time due to additional services; such services for example can be observed on ABB System 800xA Extended Automation. The new automation platform supports real-time system information retrieval and enables decision making right away and has collaborative platform for effective operation [1]. In order to provide a solution to such inevitable industrial demands, a component-based software development has to be extended to address real-time behavior of control application. And this has been possible by implementing a real-time component based development framework.
Real-time component-based software development addresses timeliness and predictability demand of real-time control applications. In fact, similar functionality can be achieved with the use of processes, semaphores, and message queues; however, their implementation has the tendency to incur runtime overhead as compared to real-time component due to frequent context-switches. In addition to using real-time component based development, application need to be distributed across multiple devices; e.g., hosts, cores to share execution load. In the following section we will discuss Future Automation Software Architecture, FASA in detail - an example to real-time component-based software development by ABB research group [2].
10 An Interface is with a component is a point of access point based on a well defined and accepted
15
Future Automation Software Architecture (FASA)
FASA [2] [11] [12] [13] is a Component-Based Real-Time Software Development platform with its own runtime environment, deployment and management platform. It supports two modes of application development, fast and safe mode. At compile time, the platform enables software engineers to select either one or both mode. Fast mode enables applications to execute in a single process; as a result, components reside in the same address space and communicate through shared memory. Applications developed using fast mode executes faster; however, may introduce memory corruption due to share memory. On the other hand, safe mod allows components of the same application to reside in a separate and dedicated address space; as a result, memory corruption is technically avoided.
Figure 4: FASA framework
FASA framework consists of FASA kernel, FASA framework manager and a schedule policy. Each FASA kernel instance provides a FASA framework manager. The manager is responsible for managing execution of a distributed application at runtime such as schedule policy change and component related operation; e.g., start and stop component execution.
1. FASA Component Framework
FASA component framework comprises the following structural elements: Component, Block, Port and Channel. A Component in FASA provides isolation of software application parts by encompassing one or more blocks. A block is a sequence of software instruction that defines FASA unit of execution. Data communication between blocks is achieved through Channels. A channel in FASA is implemented as a one-to-one and unidirectional communication between ports defined in blocks willing to transfer data. A port is a data type interface, which is identified as input/output port, holds data for receiving and transmitting, respectively.
Data communication between blocks is made possible through three different mechanisms depending on components relative deployment.
- Components within the same address space – blocks within a single component or components with the same address space use shared memory for data communication. As compared to other communication types discussed below, it has low communication latency due non-context switching, but high possibility of memory corruption11 .
11 Violation of memory location integrity caused by processes interference which ultimately causes
program crash or undesirable behaviour, wiki
HOST OS
FASA KERNEL FASA Framework Manager
Schedule Policy A p p li ca ti o n FASA framework B1 channel B2
component Application block port
16
Figure 6: Shared memory communication mechanism
- Components on different address space but within the same Host – FASA implements System V message queue12 for data communication between blocks residing on different address space. This type of communication also applies to components located at separate cores within the same host. A sender block sends message to a shared queue asynchronously while a receiving block retrieves the message synchronously which means the receiving block will be blocked until data is available. This is to avoid faulty data retrieval by the receiving end.
Figure 7: Message queue communication mechanism
- Components on different host (physically or virtually separated hosts) – FASA uses a network proxy to achieve data communication between blocks residing on physically different machines. A network proxy is an application layer protocol based on client-server model which acts on behalf of sender or receiver end. A block ready to send data uses a Network Send Proxy; similarly, a block ready to receive data uses Network Receive Proxy. The network proxies,
Netproxy, are special blocks in FASA. They are scheduled like a normal FASA
blocks to execute immediately after a sender block or before a receiver block.
Figure 8: Netproxy communicating mechanism
12 Message queue implementation of System V (aka SysV) which is one of the pioneer Unix OS
Sender Block Receiver Block
Shared memory
Write Read
Sender Block Receiver Block Data area
Write Data area Read
Message Queue
Msg_send Msg_receive
Sender Block Receiver Block
Data area
Write Data area Read
Msg_send Msg_receive Network Send Proxy Network Receive Proxy Network
17
Virtualization
Application of virtualization dates back to 1960s when IBM mainframe was started to host multiple applications sharing the same physical resource and running simultaneously. Since the acquisition of x86 based machines and desktop OS such as windows and UNIX, virtualization evolved to refer to a large scale of applications such desktop level, OS level and application level virtualization [14]. The definition of virtualization is buzzword and is defined differently by different authors even today; however, there is a general consensus on the basic concept and application of virtualization. It mainly refers to logical partitioning of physical computing resources regardless of the physical location; and by doing so operational cost is minimized and investment is reduced. The most obvious computing resources to be virtualized are processor, I/O device, memory, communication and storage. And virtualization technology is used in academia and business mainly through desktop virtualization and cloud computing [15]. It’s quite important to differentiate virtualization from emulation. Both of them involve imitation of computing resources as though they exist in reality; however, the methodology and purpose is different. Emulation imitates a hardware or software of interest by translating instructions from one form to another. For example, QEMU is an emulator; we can create or emulate a PCH HDA adapter regardless of the underlying hardware sound adapter is, e.g., it could be Sound blaster. Virtualization uses hypervisors to partition and manage computing resources. An emulator is usually used for testing different processor and peripheral devices for which it is not designed for, avoiding hardware or software expenses; and also is used in virtualization to emulate some devices to the virtual machine.
Components of virtualization
Virtualization has two main components: a hypervisor and guest machines. A hypervisor is a piece of software (aka called a Virtual Machine Monitor, VMM) that manages resources such as CPU, memory and interrupts used by virtual machines. Depending on CPU mode13 a
hypervisor is classified into two types (it is not a clear cut classification though):
1. Type-1 or Bare metal hypervisor (Figure 10: Type 1 hypervisor) – executes right on top of a hardware layer with privileged mode as compared to guest machines. And guest machines run on top hypervisor with restricted mode of operation. Example, Citrix XenServer, VMware ESX/ESXi.
2. Type-2 or operating system level hypervisor (Figure 9: Type 2 hypervisor)– operates on top of conventional operating system such VMworkstation and VirtualBox .
13 The two main CPU modes are privileged mode and restricted mode. Unless a program (a
hypervisor or OS) is in privileged mode some instructions are not allowed to execute. http://en.wikipedia.org/wiki/CPU_modes
Figure 10: Type 1 hypervisor
18 2.2 Technological Background
Xen Hypervisor (Xen pronounced /’zɛn/)
XenHypervisor is an open source hypervisor developed by Xen Project Team14. It is a
Virtual Machine Monitoring, VMM comprising lightweight software program (<150,000 lines of code) that manages CPU, memory and interrupts for guest machines. Neither does it manage I/O transaction nor does it manage guest machines. Instead, there is a privileged guest machine, Dom0 which is ported with host OS usually from UNIX flavor (Linux, FreeBSD distributions) which manages guest machines and device drivers. Xen is a type 1 hypervisor; and is base to XenCloud platform and XenARM.
The Xen architecture has the following components:
1. The Xen hypervisor – manages CPU, memory and interrupts to guest machines 2. Dom0 – a control guest machine which has driver support for guest machines
and tool stack to manage DomU.
3. DomU – a guest machine which run under restricted mode with their own OS 4. Xen Tool stack15 – an interface in command line or graphical to manage the guest
machines.
5. Modified kernel – Xen requires a modified kernel to act as a Dom0 usually found from the mainline kernel or build from source.
Xen hypervisor supports three types of virtualization:
1. Paravirtualization (PV) – is the first type of virtualization supported by Xen. This type of virtualization requires a modified guest machine drivers (aka backend drivers) on the Dom0 side and a frontend drivers on the DomU side. DomU I/O access is through Domo backend drivers. Dom0 has the actual driver to communicate with Host hardware.
2. Hardware Virtual Machine (HVM) aka Full virtualization – this is type of virtualization is supported on host machines with virtualization extension such as Intel VT-x. Hardware resources such CPU, memory and I/O are emulated
14 Xen Project: http://www.xenproject.org/
15 Xen toolstack: http://wiki.xen.org/wiki/Choice_of_Toolstacks
X e n c o m p o n e n ts Dom0 (Management guest machine)
Xen Hypervisor
Schedule MMU
toolstack Backend driver Qemu-Xen PV Guest Machine DomU Frontend driver HW drivers PVHVM Guest Machine DomU Frontend driver HVM guest machine DomU Xen virtual firmware Host HW19
using QEMUL device emulator. Qemu-xen16 is the Xen flavor of QEMU; it
provides a virtual firmware to DomU by giving the impression that the guest machine is running directly on physical machine. Emulation is processor intensive and as compared to PV, HVM performs less in I/O throughput. To solve this problem, Xen team introduced PCI pass-through in Xen hypervisor. PCI pass-through enables DomU to access I/O devices directly without the emulation using Input/Output Memory Management Unit, IOMMU (Intel VT-D and AMD IOMMU) to boost communication performance between I/O devices and DomU. 3. Paravirtualization on HVM – this is a recent feature introduced on Xen-4.3 release. It boosts HVM performance using PVHVM drivers (an optimized PV driver for HVM); therefore, without the need for QEMU device emulation. A kernel feature PVOPS in the host machine identifies for virtualization mode and then divers driver request to use PVHVM drivers. Therefore, the HVM network and disk access uses paravirtualization method (with modified driver) instead of emulation.
Open vSwitch
Open vSwitch (open virtual switch) is a switch specially designed for bridging virtual machines to physical network [16]. It is based on Software-defined Networking, SDN approach which emphasizes the need for separate control and data plane17. Linux-bridge is
the default birding in Linux for virtual machines; however, it’s not designed to support multi-server virtualization18; as a result networking in virtualization tend to go to more advanced
virtual switches such as Open vSwith and Indigo.
Openvswitch operates at user and kernel space mode. The kernel module, openvswitch_mod.ko processes and forwards packet entering a physical network interface. If bridging traffic to virtual machine is required or advanced switch configuration is needed the packet is forwarded to ovs-vswitchd at user space. Initial switching configuration is stored at ovsdb-server and using JSON/RPC, the configuration is offloaded into flowTable. After creating a bridge, a physical Ethernet configuration is no more used.
16 Qemu-xen: http://wiki.xen.org/wiki/QEMU_Upstream
17 SDN: http://en.wikipedia.org/wiki/Software-defined_networking 18 Why openvSwitch? :
http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=blob_plain;f=WHY-OVS;hb=HEAD O p e n v S w ti ch c o m p o n e n ts Ovsdb-server Ovs-vswitchd (slow path) Packet classifier FlowTable Openvswitch_mod.ko (fast path) Kernel mode User mode Hash_lookup Table Eth 0 JSON/RPC (management) NetLink xenbr0 xenbr1
20
4DIAC-IDE
Framework for Distributed Automation and Control, 4DIAC is a free, open, IEC 61499 standard compliant automation and control environment. One of the projects by the 4DIAC initiative is 4DIAC-IDE. It is an integrated development environment of IEC 6199 compliant automation and control, based on Eclipse framework.
An IEC 61499 standard provides the architecture, tools and rule of compliance for development of distributed automation and systems [17]. It addresses shortcomings of its predecessor, IEC 61131 standard e.g., programming language independence but moreover it provides distribution and dynamic reconfiguration. The atomic execution unit of IEC 61499 standards, Functional Block, FB is the construct of an application. It has event and data connection to interact with other FB or the environment as indicated by red and blue lines in the 4DIAC-IDE. An application is developed by interconnecting FB instances and allocating them a resource19. And the FBs are distributed to physical devices across a network. Events
trigger actions by executing algorithms within the FB according to Execution Control Chart, ECC [18]. And an executed algorithm pushes data to the output I/O for transmission.
4DIAC-IDE has three main perspectives20 for developing an application based on
functional block semantics defined by IEC 61499 standards.
1. System management perspective - this is the main perspective where control applications are modeled, devices and resources are configured
2. Type management perspective – is the perspective for managing IEC 61499 compliant types such as using pre-existed FBs, creating blocks and editing functional blocks.
3. Deployment management perspective – finally a system configuration (resources and devices) is prepared and application deployed on controllers launched using runtime programs such 4DIAC - Runtime Environment, FORTE.
19 Resources can be considered processor cores, memory, bandwidth … provided by devices. 20 4DIAC-IDE Quick start:
http://sourceforge.net/apps/mediawiki/fordiac/index.php?title=4DIAC-IDE_Quickstart
21
Chapter 3
Development of Orchestra components
The Orchestra application is a composite of components where each component provides a service, e.g., rhythm message and timing specification to another component. The component service is defined using functional blocks modeled using 4DIAC-IDE tool based on IEC 61499 standards and executed on FASA runtime environment (aka FASA kernel). The application constitutes a total of 17x components and 17x functional blocks. Software tools employed during development are FreeMind for mind mapping, Umbrello UML modeling tool (Use Case Model and Sequence diagram), 4DIAC-IDE and FASA for modeling and implementing orchestra application21. In the following subsequent topics, we will discuss the
development approach, preliminary study of orchestra in music, and modeling and implementation process: Defining requirements, modeling and implementation using the software tools mentioned above.
3.1 Component development mechanism
Initially orchestra application components are developed and implemented using 4DIAC-IDE. Then using 4diac-fasa plug-in, the model is transformed to FASA component model framework where execution of the application is performed. FASA component framework does not have its own IDE; instead, the plug-in is used to transform some of the features of 4DIAC-IDE e.g., basic functional block, sub-application of 4DIAC to blocks and components in FASA. By the time of report writing, basic 4DIAC-IDE features such as device creation, resource allocation and deployment is not supported by the plug-in; as a result, it is done manually.
4DIAC-IDE is build by cloning to the source hosted on sourceforge.net. Then 4diac-fasa plug-in is imported to the set of 4DIAC-IDE plug-ins before building it. The built IDE gives us an eclipse-IDE with 4DIAC features and automated transformation for 4DIAC-to-FASA. The plug-in enables an application engineer to use 4DIAC-IDE to develop application for FASA framework which provides visualization instead of textual work on FASA; however, the transformation is not smooth enough perhaps is under further development. The transformation result is a set of files and directories regarding components and functional blocks; these need to be copied manually to respected structural tree on FASA. Due to this, for every update on the model, it is not reflected automatically on the FASA. I believe this has to do with the deployment feature of 4DIAC not automated for FASA. The perspective is used to deploy an application on a selected runtime environment, similar to FORTE and FBDK22,
which can be a prototype for FASA integration in the deployment perspective. We suggest FASA deployment process be integrated in the deployment flow of 4DIAC-IDE in the future.
Before diving into the development process, it’s important to understand the context of orchestra in music such as organizational structure, role, communication and synchronization of musicians; and features adopted or imitated to our orchestra application.
21 Does not include resource allocation and device assignment of components, this is done using
FASA framework.
22 3.2 Orchestra organization
An orchestra23 is a large instrument ensemble usually led by a conductor and principals
or sub-conductors. As a rule of thumb, the conductor is responsible for leading the whole orchestra while the principals rehearse a certain group of musicians with similar quality of instruments such as string, percussion, woodwinds and brass. The flow command for playing the orchestra comes from top hierarchy and goes through principal at second level. The basic orchestra activities are imitated to suit the project intended objective that is timeliness and predictability in multi processing environment. If the instrument is played before or after an anticipated time (which is indicated by rhythm note), the orchestra goes out of sync. Out-of- sync implication in this context implies to latency and jitter introduced during execution of components in the virtualized multicore environment and transmission. According to study [9] on human perception to such effects, many researchers share the conclusion that 20-30 ms sound delay is tolerable by our ears. What is more interesting about sound produced by orchestra is human capability to follow rhythm even at slight deviation of 4ms at sub conscious level. This has in an implication to the feedback we get from the orchestra application: the feedback we get from the orchestra application need to be within 20-30ms so that it will not be perceptible by our ears; and second even with acceptable range of latency and jitter, the quality could vary; and this is possible to notice by following the rhythm within high precision or around 4ms.
3.3 Define requirements
Automated orchestra application conceived from the concept of orchestra in real world (for example, as shown from the mind map of Royal Stockholm Philharmonic Orchestra) is a two level hierarchal of communication, which is communication between the conductor and principals; and among principals and corresponding group of musicians. Whatever is directed from the conductor is passed through the principals; and rehearsed by musicians asynchronously (in our implementation the communication goal is achieved through cyclic execution of blocks, though).
23 Orchestra wiki: http://en.wikipedia.org/wiki/Orchestra
23
The problem domain identified in the mind map is elaborated further in the Use Case Model.
Figure 15: Use Case Automated Orchestra Application
Use case name Conduct Orchestra
Participating Actors Computer Terminal User
Precondition The system is setup with roles of musicians and timing information such as start time, tempo in a configuration file.
Basic flow 1. The user launches the application by entering
‘application run’ on the terminal.
2. Parses a configuration file and stores orchestra organizational structure and rate (cycles/sec) at which the orchestra to be played in a buffer.
3. Decode midi file and save it into a buffer.
4. Creates rhythm groups24 composed of multiple tracks to be played at constant rate.
Alternative flow
Post conditions Saves the state of conducting the orchestra such as indices of the last event25 from each rhythm group and absolute time played
since the orchestra has started.
Store the generated rhythm groups in a shared memory.
Special requirements
Use case name Conduct Musicians
Participating Actors
Precondition Rhythm groups are generated and stored in a shared memory.
Basic flow 1. Reads orchestra organizational structure from a
configuration file.
2. Split the rhythm groups into a rhythm26.
Alternative flow
24 Rhythm group is a set of rhythms.
25 Event is the occurrence of ON /OFF notes indicated in MIDI file protocol standard. 26 Rhythm is a subset of events in a single musical track/instrument in a MIDI file.
24
Post conditions Stores the rhythms in a shared memory.
Special requirements
Use case name Play Music
Participating Actors
Precondition A rhythm is generated and stored.
Basic flow 1. Parses the rhythm and identify ON/OFF events.
2. Reads delta time between subsequent events.
3. For each event, the sound system is triggered preceded by a silence of delta time. And this will produce a sound on the speaker.
Alternative flow Post conditions
Special requirements A speaker should be connected to the system.
An audio system which produces a sound should be installed in the system.
A synthesizer and sound bank that interpret the notes should be installed in the system.
Automated orchestra application is initiated using a computer terminal. It could deployed eit a standalone system or distributed across a network of computer nodes. The use case, Conduct the Principals process the input files to the system and further decodes the midi file into a group of musical note which is input to another use case, Conduct the
Musicians. The later use case distributes the musical note which is finally played in Play Instrument use case. This process is repeated periodically until the midi file timeline is
finished playing.
Figure 16: Orchestra performance UML sequence diagram
conductor principal musician rhythm[]
rhythm {Forevery event in the Rhythmpaly the event}
next cycle synchronization log rhythm[] rhythm log
Index:0
Index:1
2, 3 ...
next cycle ~microsecond ~microsecondduration
25 Component specification
From the Use Case Model and mind mapping depicted above we can deduce the basic required components to do the overall functionality of the orchestra application; hence, the following components are indentified:
1. The conductor component 2. The principal component 3. The musician component
A summarized number of blocks and components required and functionality. Sub-application/
Component (FASA)
Functional Block /Block (FASA)
Functionality
1xconductorSA 1xconductorFB - Parse Midi (orchestra)
- Divide the midi into group of tracks
- Identify set of tracks based on manual conf. - Distribute (rhythm, index, duration message )
to sub-conductors/principals
4xprincipalSA 4xprincipalFB - Divide the rhythm among the musicians based on preconfigured information.
12xmusicianSA 12xmusicianFB - play the rhythm for the allocated duration
Table1: Orchestra application blocks and components and functionality
3.4 Distributed orchestra application overview
The following high level design of orchestra application a single path which is conductor-principal-musician. Likewise, the same procedure will be repeated for multiple principals and musicians. This single application which is playing an orchestra will be will be modeled and implemented in the next sub section.
O rc h e st ra a p p li ca ti o n
Parse midi file
Extract rhythm groups -tracks and events
Dispatch rhythm groups to principals
Port ? Extract rhythm
Events per track Dispatch rhythm to musicians Play rhythm Next cycle Port? Orchestra organization XML midifile Orchestra organization XML
26 3.5 Component modelling
Finally we are going to model the components based on requirements and high level design described above using 4DIAC-IDE. First we will describe a step-by-step procedure for creating the component types using 4DIAC-IDE type management perspective. Respective snapshots are to be found at Appendix A.
Step #1: Create a new project by the name OrchestraProject and fill appropriate fields.
File->New->New System and fill the project name ‘OrchestraProject’
Next, import the default Pallets for using default libraries from 4DIAC.
Fill information related to the project e.g., type, comment, description …
Go to Windows and show ‘System Manager view’, if not opened in the ‘System
Manager perspective’; the created project will be available there.
Step #2: create the functional blocks
Shift perspective to ‘Type Management->Type navigator view’.
Select and right-mouse click on OrchestrProject and create a new folder,
orchestra; it can be any name for that matter.
Right-mouse click on the new folder and go to ‘New Type’
Give a name to the block e.g., conductorFB of ‘Type’ basic block.
Create input and output variables as indicated in Appendix
Repeat this for principal and musician basic blocks (aka functional block in IEC 61488 standard naming)
Step #3: Create orchestra application and use the blocks created in step#2
Go to ‘System Manager’ and right-mouse click and select ‘New application’
Give it a name ‘orchestra’
Drag and drop the blocks created
Connect the event and data channels
(Note: Since device and resource allocation is not supported by 4diac-fasa transformation plug-in, manual configuration is done. This is only to indicate the work flow of 4DIAC-IDE). The following diagram is a result of a subsequent steps discussed above.
Following orchestra component modelling on 4DIAC-IDE, let’s have a look on the code or template generated by 4diac-fasa transformation plug-in.
Figure 19: conductor functional block Figure 17: principal functional block
Figure 18: musician functional block
27 3.6 Template generated by 4diac-fasa plug-in
The transformation plug-in generates a template for the application developer to start with writing algorithms. The template is a collection of directories within are found configuration files and C++ source and header files. These are discussed in detail below:
Application directory
This directory holds XML files for each sub application or components modeled in the 4DIAC IDE. These XML files describe a component such as name and related component implementation path. According to modeling, there are 15 XML files that describe a component (1xconductorSA, 2xprincipalSA and 12xmusicianSA). Other XML files includes: and a single XML for a single host the kernel will be executing.
- Orchestra.xml –a communication and schedule configuration on a single host. - Orchestra_net_master.XML – a communication and schedule configuration for
the conductor when application is distributed across multiple virtual nodes. - Orchestra_net_swartxx.xml – a communication and schedule configuration for
principal and musician when application is distributed across virtual nodes. - Swartxx_net_receive/send.xml – a configuration setup for receiving and
sending proxies; xx refers to host name.
Library directory
This directory holds a template for actual C++ source and header files on a separate folder for blocks and components.
- Methods – algorithm which describes the behavior of a block - Variables and State – input/output of blocks and state of a block.
28
Module directory
This directory holds a single configuration file which describes location of each component and block in the application. A compiler refers this configuration for reference of blocks and components.
#include "conductorFB.h" #include <iostream> #include <cstdlib> namespace FASA { namespace Libraries { namespace conductorFB { void conductorFB::operator () () { //algorithm } void conductorFB::construct () { FASA_REGISTER_OUT_PORT (OM); FASA_REGISTER_OUT_PORT (MDO); } } // namespace masterapp } // namespace Libraries } // namespace FASA #include "conductorSA.h" #include <iostream> using namespace std; #include "../blocks/conductorFB.cc" namespace FASA { namespace Libraries { namespace conductorSA { conductorSA_Component::conductorFB _Component (const ID &id, const std::vector<std::string> ¶meters,
Model::Component::State *state) : Component (id, parameters, state) {
blocks.set ("conductorFB", new conductorFB("conductorFB", this)); } void conductorSA _Component::init () { } } // namespace conductorSA } // namespace Libraries } // namespace FASA
Figure 20: conductorFB and conductorSA C++ templates
3.7 Standard Midi file format and partitioning
Standard MIDI file format
MIDI (Musical Instrument Digital Interface) is a technical standard published by Association of Musical Electronics Industry (AMEI) which defines a protocol, digital interfacing and communication of musical instruments, computer system and other devices. MIDI uses event message to communicate among digital midi devices which basically specifies music notation, pitch, velocity and others. One way of carrying these messages is using MIDI file as compared to midi sequencers which also is used to edit and play music.
The format of MIDI file used in the scope of works is produced by International Midi Association, EMI [19]. The file block is made up of chunks and events. Only relevant parts are discussed below:
Chunk – is a sequence of 8-bit byte with the following format.
<type:4byte><length:4byte>:<data:lengthofdata>
There are two types of chunks: Header Chunk and Track chunk identified by the keyword type as ASCII character “MThd” and “MTrk”, respectively. Header Chunk specifies basic information about the data in the midi file; such as number of tracks and other information. Whereas, Track Chunks the actual chunk which holds the musical song in a form of events.
Event – are part of a data section in a Track chunk. There is variable number of events in a track; for instance, middle C key in a piano can be represented as a
29
single event followed by D key. The time difference between the two notes is called delta-time. The unit of measurement can be ticks or milliseconds.
Event: <delta-time><event>
There are three event types: meta-event, data-event and sysex events. Actual songs are specified in data-events [19].
MIDI file block: CHUNK
Type Length Data
MThd 6 …<track>…
MTrk <length> <delta-time><event> ….
MTrk <length> <delta-time><event>
Table 3: midi file format Software tools and libraries
Midi file simply holds MIDI notation and controls; therefore, once parsed the midi file. A series of steps is required to produce the actual sound from the speaker. Following are the tools used:
Fluidsynth – is an open source software synthesizer27 which converts midi data
into audio signal using SoundFont technology28. The orchestra application uses
fluidsyth development API to produce sounds based on a midi note data. Please
PulseAudio 29– is the default sound server in Ubuntu which accepts sound
requests from multiple applications for concurrent access and other advanced audio processing services. For example, the orchestra application and Rhythmbox application (player in Ubuntu) use the sound card concurrently through PulseAudio.
ALSA30 – PulseAudio does not contain any drivers for underlying sound cards;
instead, it uses Advanced Linux Sound Architecture, ALSA to communicate with sound cards. ALSA is the default audio infrastructure in Ubuntu OS and has supports for many sound card vendors31 as compared to its predecessor OSS32.
27 Software which imitates and produces sounds of instruments using programming algorithms. 28 Maps recorded and synthesized audio; especially for music composition.
29 PulseAudio: http://www.freedesktop.org/wiki/Software/PulseAudio/
30 ALSA: http://www.alsa-project.org/main/index.php/Main_Page. Aug 14, 2013 31http://www.alsa-project.org/main/index.php/Matrix:Main#ALSA_SoundCard_Matrix 32 OSS: http://www.opensound.com/oss.html. Aug14, 2013
Sound Card (Intel HDA) ALSA PulseAudio Others App Orchestra application flu id sy nt h
30
Midi file partitioning and rhythm message
The midi file is partitioned into a set of events per track (also called rhythm in the scope of work). The even types we are interested in are ON_event and OFF_event. ON_event indicates start of playing a key note; and OFF_event indicates end of playing a key note. The orchestra application uses fluid_synth_noteon() and fluid_synth_noteoff() APIs from playRythm() routine to enforce ON_even and OFF_event on midi driver through synthesizer.
/* Rhythm information */ struct Rhythm { MFEvent *mfevent; int track; int start_index; int end_index; int absolute_tick; int absolute_tick_played; int cycle; int ticksPerQuarterNote; }; Description -Midi events -Track number
-Start of event index in midi -End of event index in mid -Start of tick number in the midi -Absolute tick plus duration in tick -The number of cyclic execution -Number of ticks needed to sound a quarter note, used for conversion from tick to seconds
Table 4: Rhythm message format
A rhythm message is a message transmitted by the conductorFB block to the musicianFB through principalFB. It is used to direct the musician what to play and for how long to play. This message is sent periodically according to cyclic execution of FASA blocks. Since FASA modeling is periodic, any variable number of events is treated by the musician within that period. M id i e ve n ts p a rt it io n in g duration Start_abs_time = 0 0 1 ON_event OFF_event Track#1 Track#n rhythm
31 C o n d u ct o r fl o w d ia g ra m Extract rhythm group Dispatch rhythm group to principals End of a cycle Orchestra organization XML midifile State -event index -abs time p ri n ci p a l f lo w d ia g ra m Extract rhythm Dispatch rhythm group to musicians End of a cycle Orchestra organization XML Receive rhythm group from conductor
3.8 Algorithm Implementation for functional blocks
Conductor Functional Blocks implementation
The conductor functional block, conductorFB implements the conductor functionality in the orchestra. It reads midi file and orchestra organization XML and cyclically dispatches rhythm group (rhythm message for multiple tracks) to principal functional blocks. It supports four principal functional blocks, from CH0O to CH3O.
The conductorFB sends rhythm group according to predefined prinicipal-port mappings from orchestra organization XML file.
Since FASA blocks are stateless, the conductorFB has a separate state structure, conductorFB_Block_State() to hold rhythm information (index, absolute tick) of a previous rhythm message.
Principal Functional Block implementation
The principal functional block, principalFB implements the functionality of sub conductor in the orchestra. It receives a group of rhythms from the conductor and dispatches the rhythm based on preconfigured track information from orchestra organization XML.
Table 5: conductor flow diagram
32
Musician Functional Block implementation
The musician Functional block, musicianFB implements the functionality of musician in the orchestra. It receives a rhythm from principal functional block and plays by referring the event index and duration from the rhythm message.
Whenever the rhythm player is encountered with ON or OFF events, there is always a delta time proceeded to it. And this delta time is used to delay or hold the note for that time, event.time. If the musicianFB did not encounter events for one or more cycles, the delta time is accumulated for at least the ‘duration x the number of cycles not played’. And by the time an event arrives the musicianFB, it tries to hold the note for the prolonged amount of time which is not correct. Instead, it is expected to delay since the the latest musicianFB cycle start. For this reason, we need a state to save the number of cycles the block did not encounter events; and then refresh it once encountered to zero.
p ri n ci p a l fl o w d ia g ra m Play rhythm End of a cycle Receive rhythm from principal State cycle_not_pla yed Port connected ? yes start start 1 2 cycle
Delay provided by the event: not applicable (delta)
Correct_delay Correct_delay = delta – duration x cycle
ON event OFF event
duration
?
