Chapter 3 System Design and Implementation
3.3 Implementation of Visual MMI Development for Storage Systems
3.3.5 Generic MMI Engine
The kernel component of the Visual MMI Development for Storage Systems is Generic MMI Engine. This engine can manipulate the data from Visual Authoring Process. Figure 20 illustrates the block diagram of Generic MMI Engine.
Figure 20. The Block Diagram of Generic MMI Engine
We design and implement five modules of Generic MMI Engine. They take different responsibilities. Table 4 summarizes these modules, and we describe the details design of these different modules in the following paragraphs.
Table 4. Modules of Generic MMI Engine
Module Name Description
MmiMain Main functions of MMI engine MmiData MMI data from visual authoring MmiDisp MMI display functions
MmiAct Interface between MmiMain and MmiData MmiSub Interface between MmiMain and MngApi
1) MmiMain Module: This module contains main functions of Generic MMI Engine.
MmiMain_Entry( ) is the entry function of engine and it invokes three sub-functions:
mmiMain_Initialization( ), mmiMain_NormalMode( ), and mmiMain_Finalization( ). All
initialization will be done in the mmiMain_Initialization( ). In this function, we init the data pointer to MMI Data, set active layer and node, and initialize MmiDisp and MmiSub modules. The mmiMain_NormalMode( ) function is the core of Generic MMI Engine. It invoke functions of MmiDisp module to display screen and menus, and functions of InputApi to get input from users repeatedly. After get any input, it dispatch tasks to take correspondent actions. In the mmiMain_Finalization( ) function, we finalize something before leaving, e.g. finalize MmiSub module and restore the display mode, etc.
2) MmiData Module: The MmiData.h is the output of SVG Parser. During compilation phase, we use SVG Parser to read the wanted SVG file and elicit MmiData.h automatically. In Generic MMI Engine, it reads and writes the data structures in MmiData module by MmiAct and MmiSub modules, but read only by MmiDisp module.
3) MmiDisp Module: This module contains functions for display. For instance, the MmiDisp_DrawScreen( ) draws the Screen MMI element, and the MmiDisp_DrawLayer( ) function draws the Layer MMI element. These functions of MmiDisp module need low-level functions support, i.e. they invoke the functions of Display API (DispApi). We separate the display functions with OS dependence to Display API.
4) MmiAct Module: This module contains functions for the Node MMI elements.
MMI programmers must add the related functions into MmiAct module, and edit the SVG file to add the related function name into Node MMI elements, e.g. the MmiAct_CtrlInfo( ) function for node_CtrlInfo, and the MmiAct_PdMng( ) function for node_PdMng, etc.
5) MmiSub Module: Functions in this module are sub-functions for MmiMain and MmiAct modules. These functions cooperate with Management API (MngApi) to get information from Embedded Firmware. For example, the MmiSub_PdEnum( ) function gets the ID of physical hard disk drives and enumerate all of them in the storage system.
The MmiSub_FillPdInfo( ) function gets the information of physical hard disk drives from Management API (MngApi) and fill the strings for MmiAct module.
Besides above modules, there are some API libraries will cooperate with Generic MMI Engine. They are:
1) Input API (InputApi): Input API provides functions to get input from users, e.g.
what key is pressed, or the coordinates of mouse cursor, etc. This API is OS dependent. For the Booting Utility of storage systems, we write assembly sub-routines or invoke software interrupts of system BIOS.
2) Display API (DispApi): This API provides functions to display MMI elements.
Using more powerful Display API, we can implement more functional Generic MMI Engine to display complex SVG graphics. For instance, the DispApi_GetDisplayMode( ) function gets current display mode, and the DispApi_CursorDisable( ) function can hide cursor. Of course, this API is also OS dependent.
3) Management API (MngApi): The Management API is the library has capability to communicate with the Embedded Firmware of storage systems. It allocates a private data buffer to get information from firmware, and provides related functions to fetch items in that buffer. E.g. the MngApi_GetPdInfo( ) function gets the information of assigned physical hard disk drive into data buffer, and the MngApi_FetchPdId( ) function fetches the ID of that physical hard disk drive from data buffer. The Management API is dependent on storage systems.
Chapter 4
Simulation and Application Examples
In chapter 3, we describe the design and implementation of Visual MMI Development for Storage Systems. In this chapter, we will demonstrate simulation examples for the Booting Utility and application examples for the Pre-OS Utility of storage systems. We will follow the framework of Visual MMI Development for Storage Systems, and implement these examples step by step.
4.1 Simulation Examples for the Booting Utility of Storage Systems
Before implement the simulation and application examples, we define the MMI requirement specification for them in Figure 21. We simply define four menus to demonstrate the basic functions for MMIs of storage systems.
Figure 21. MMI Requirement Specification for Simulation and Application Examples
The usage scenario of this system is as below description. The first menu is main menu that contains some nodes, but only two nodes are functional. They are the node
“Controller Information” and “Physical Drive Management”. When users press the node
“Controller Information”, it will pop up the menu “Controller Information” that displays the information of adapter controller. When users press the node “Physical Drive Management”, it will pop up the menu “Physical Drive Management” that has a table lists present physical hard disk drives. When users want to read the information of certain physical hard disk drive, they can press it and the menu “Physical Drive Information” will pop up.
To implement this simulation example for the Booting Utility of storage systems, we follow the steps in section 3.1 Visual MMI Development for Storage Systems.
Step 1) MMI designers use Visual Authoring Tool to compose wanted MMIs according to MMI requirement documents. We compose wanted MMIs in Visual Authoring Tool -- Inkscape. In figure 22, we compose the screen layout first, because it is the root layer.
Figure 22. Compose Screen Layout by Inkscape
The first row of the screen layout is the screen title, and the second row in dark gray background color is Navigation Bar (NaviBar). In this bar, we can display the hierarchy of active menus, e.g. “Main Menu > Physical Drive Management > Physical Drive Information”.
The bottom row of screen is Message Bar (MsgBar). In this bar, we can display messages, e.g.
the brief hint of hot keys. The rows between NaviBar and MsgBar are the canvas that we can place menus.
Step 2) Save the results of Visula Authoring Tool as SVG Files. In default setting, Inkscape saves files in SVG format. Figure 23 illustrates a partial SVG file in plain text.
Figure 23. SVG File in Plain Text
Step 3) To speed up the development of MMIs, we can create Template SVG Files for MMI designers. We compose the Template SVG File in figure 24 with Menu Template (layer_MenuTemplate) that has key elements for each layer of menu.
Figure 24. Compose the Template SVG File
These key elements are Navi Bar, Menu, Node, and Msg Bar. Navi Bar is a row for navigation, and it displays the hierarchy of active menus. Menus include menu title, heads of items, contents of items, and nodes. Nodes are special text elements with the ability to combine the function and child menu together. If users select one node in the running time, it will take the related function and then pop up its child menu. Msg Bar is a row to display messages or hints for users. For example, we can list hot keys for active menu particularly.
Using the layer of Menu Template (layer_MenuTemple) in the Template SVG file, MMI designers can compose the wanted menus quickly. Figure 25 illustrates three menus were been composed by using the layer_MenuTemple: Main Menu (layer_1_MainMenu), Physical Drive Management Menu (layer_2_PdMng), and Physical Drive Information Menu (layer_3_PdInfo), and other menu layers are hidden: Controller Information Menu (layer_2_CtrlInfo), Menu Template (layer_9_MenuTemplate), and Debug Layer (layer_9_Debug). In the right bottom corner of figure 25, the Layer Manger of Inkscape can control these layers.
[ String of menu title ]
String of head : String of content
String of node
Figure 25. Compose Menus by Using the layer_MenuTemple
Step 4) For developers or customers, they can preview these SVG Files in web browsers. During the Visual Authoring Process, we can use web browser to preview SVG files. In order to let web browser displays texts in SVG files correctly, we have to set texts as Unflow. In Inkscape, select wanted texts and choose the function: Text > Unflow.
Step 5) MMI programmers add additional information in SVG Files. We use the XML Editor of Inkscape to edit the SVG elements, and give the meaningful names and attributes for MMI elements in Menu Template (layer_MenuTemplate). For instance, we give layer_1_MainMenu as the name of main menu layer, and the attribute of layer_2_CtrlInfo as the child menu for node node_CtrlInfo. This means that users press the node of node_CtrlInfo, and Generic MMI Engine will display the MMI elements in layer_2_CtrlInfo.
[ Physical Drive Information ]
Physical Drive ID : String of cont_PdId…………..
Model Name : String of cont_PdModel…….. 123 | 12345678901234567890 | 1234567890 | 12345 - | - | - | -
Step 6) Use SVG Parser to transform SVG Files to MMI Data. After we save the results in SVG files, we can use SVG Parser to generate MMI Data for Generic MMI Engine automatically. The output of SVG Parser is MmiData.h, and the following example is a partial code of MmiData.h.
/* MmiData.h - Generated by SVG Parser. Don't edit this file directly! */
CREATE_SCREEN(screen_BiosCU) CREATE_NAVI(navi_MainMenu, 8, 35, COLOR_B_WHITE, "> Main Menu") CREATE_RECT(rect_MainMenuShadow, 28, 85, 285, 154, COLOR_BLACK) CREATE_RECT(rect_MainMenuBody, 17, 63, 286, 159, COLOR_BLUE) CREATE_EDGE(edge_MainMenuBorder, 20, 67, 281, 154, COLOR_B_WHITE) CREATE_TITLE(title_MainMenu, 31, 91, COLOR_B_WHITE, "[ Main Menu ]") CREATE_NODE(node_CtrlInfo, 33, 110, COLOR_YELLOW, layer_2_CtrlInfo, according to functional requirement documents. We write the related functions for MMIs.
For each Node MMI element, MMI programmers have to add the related functions into MmiAct and MmiSub modules of Generic MMI Engine. For example, we write the MmiAct_CtrlInfo( ) function to get information of controller for node_CtrlInfo, and the MmiAct_PdMng( ) function to get a list of physical hard disk drives for node_PdMng, etc.
Step 8) Generate the target MMI applications with MMI Data, Generic MMI Engine, Management API and OS dependent API. To simplify the complexity of demonstrations, we use two definitions to configure Generic MMI Engine. First, define USE_MNG_API to indicate if it needs to invoke Management API or not. Second, define DRIVER_SIMULATOR to indicate if it simulates the reactions of driver by itself or not.
If we set USE_MNG_API to OFF, Generic MMI Engine displays MMI Data directly.
All the messages and texts are the same as the ones in Visual Authoring Tool. If we set USE_MNG_API to ON, Generic MMI Engine invokes the functions of Management API, and these functions submit related commands to driver directly.
If we set DRIVER_SIMULATOR to ON, the code of Driver Simulator in Generic MMI Engine takes actions to simulate reactions of real driver. If we set DRIVER_SIMULATOR to OFF, the real driver is required to pass commands to Embedded Firmware of storage systems.
In the simulation example, figure 26 demonstrates the Booting Utility of storage systems in the DOS Prompt of Windows OS.
Figure 26. Simulation Examples for the Booting Utility of Storage Systems
In the case one of simulation examples, we set USE_MNG_API to OFF and DRIVER_SIMULATOR to ON. The utility will display MMI Data directly.
In the case two of simulation examples, we set USE_MNG_API to ON and DRIVER_SIMULATOR to ON. The utility will display imitative information from the Driver Simulator in Generic MMI Engine.
4.2 Application Examples for the Pre-OS Utility of Storage Systems
Before the demonstration of application examples, we have to setup a platform with an internal storage system. We use a HBA (Host Bus/Based Adapter) adapter and attach two hard disk drives. One hard disk drive is SATA (Serial ATA) drive and the other one is SAS (Serial Attached SCSI) drive.
Figure 27. Application Examples for the Pre-OS Utility of Storage Systems
In order to get the real information from embedded firmware of storage system, we compile Generic MMI Engine with the Management API of storage system. The functions of the Management API have to allocate data buffer and submit management commands to driver. The driver will pass these commands to embedded firmware. After the embedded firmware handles management commands and gets the wanted results, it will transfer data by DMA (Direct Memory Access) to the data buffer of the Management API.
The MmiSub module of Generic MMI Engine uses the functions of Management API to fetch particular items in the data buffer, and copy them into MMI data of Generic MMI Engine.
In the application examples, we demonstrate the Pre-OS Utility of storage systems in the Pre-OS environment, e.g. pure DOS (Disk Operating System). Of course, we must set the configuration USE_MNG_API to ON and DRIVER_SIMULATOR to OFF.
For the case one of application examples, we execute this utility and enter the menu
“Controller Information“ to get the information of adapter controller, enter the menu
“Physical Drive Management” to get a list of present physical hard disk drives, and the menu
“Physical Drive Information” to get the information of assigned physical hard disk driver. To verify the correction, we can compare the information with the results displayed by the Embedded Utility of storage systems.
For the case two of application examples, we plug off some hard disk drives and check the list of present physical hard disk drives in the menu “Physical Drive Management” and
“Physical Drive Information”. Then, we plug in some hard disk drives and enter the above menus to check again.
Chapter 5
Conclusion and Future Work
In this chapter, we draw out the conclusion of this thesis to see the design and implementation can meet the motivation and goal or not, and then we point out the future work for Visual MMI Development for Storage Systems.
5.1 Conclusion of This Thesis
In this thesis, we design and implement the Visual MMI Development for Storage Systems, and derive the Generic Software Framework for the MMI Generation of Storage Systems. Figure 28 highlights the Visual Authoring Process of Visual MMI Development for Storage Systems.
Figure 28. Visual Authoring Process of Visual MMI Development for Storage Systems
In the Visual Authoring Process, we use Visual Authoring Tool -- Inkscape, SVG Files, SVG Parser, and MMI Data. The benefits of Visual Authoring Process are:
1) MMI designers, e.g. art designer, or product’s customer, use Visual Authoring Tool -- Inkscape to compose MMIs directly. Reduce any misunderstanding and the gap of knowledge between MMI designers and programmers.
2) Programmers can add related attributes in SVG Files directly, and use SVG Parser to generate MMI Data automatically. Therefore, MMI Data is seamless with the MMI requirements, and the time to program MMI elements is also saved.
Figure 29 highlights the Generic MMI Engine in the Visual MMI Development for Storage Systems.
Figure 29. Generic MMI Engine for the MMI Generation of Storage Systems
To apply the Generic Software Framework for the MMI Generation of Storage Systems, we implement Generic MMI Engine that manipulates MMI Data, i.e. the output of Visual Authoring Process, and cooperates with Management API. The Benefits of Generic Software Framework for the MMI Generation of Storage Systems are:
1) Generic MMI Engine is a common code, and can manipulate multiple MMI Data.
Therefore, programmers can maintain MMI programs easily for serial products and different customers.
2) The design of Generic MMI Engine is OS independent, and the OS dependent functions are separated to OS Dependent APIs. Therefore, we can implement it for various OS environments easily.
After the design and implementation of Visual MMI Development for Storage Systems and Generic Software Framework for the MMI Generation of Storage Systems, we also demonstrate the feasibility and applicability of Visual-Based User Interface Construction Methodology.
5.2 Future Work
In the design and implementation of Visual MMI Development for Storage Systems, we choose Inkscape as the Visual Authoring Tool. It is an open source software and powerful graphic editor, but we can improve it with the following features:
1) Support Replay Feature: MMI designers compose wanted MMIs in Inkscape, but they are static graphics. If Inkscape can support replay feature to demonstrate the relationship between nodes and their child menus, we can get an interactive prototype more conveniently.
2) Provide Function Binder: Currently MMI programmers use XML Editor of Inkscape to add the related functions for MMI elements. If Inkscape can provide the function binder to select the wanted function in API library and bind it to the related MMI element, this is more user-friendly for MMI programmers.
Reference
[1] DoSTOR 存儲入門：圖文闡釋 DAS、NAS、SAN
http://www.dostor.com/i/basic/2006-09-22/0006129755.shtml
[2] EFI (Extensible Firmware Interface) http://www.intel.com/technology/efi/
[3] Ian Sommerville, Software Engineering, 6th edition, Addison-Wesley, 2001
[4] Chwan-Hung Wang, “On the Enhancement of an Multimedia Authoring tool for the Visual-Based User Interface Requirement Representation”, N.C.T.U. Taiwan, Master Thesis, 2002
[5] Jai-Chen Dai, “Visual-Based User Interface Generator”, N.C.T.U. Taiwan, Master Thesis, 2002
[6] Shang-Ting Yang, “User look & Feel Design for Handset Devices Based on Visual Requirement Authoring and Program Generation Methodology”, N.C.T.U. Taiwan, Master Thesis, 2004
[7] Ming-Jyh Tsai, “Generating User Interface for Mobile Devices Using Visual-Based User Interface Construction Methodology”, N.C.T.U. Taiwan, Doctor Thesis, 2007
[8] Chien-Chung Lin, “A Generic DSC Software Framework in Handset Device” , N.C.T.U.
Taiwan, Master Thesis, 2005
[9] Meng-Xi Zhuang, “XMMI – Extensible Man Machine Interface System”, N.C.T.U.
Taiwan, Master Thesis, 2004
[10] Ming-Chao Huang, “Extensible MMI system for mobile device and it’s rapidly prototyping”, N.C.T.U. Taiwan, Master Thesis, 2005
[11] Po-Chang Liu, “A Generic Software Framework for the Software System Architecture Design and Implementation of Handset Devices”, N.C.T.U. Taiwan, Master Thesis, 2005 [12] Inkscape – Open Source SVG Editor http://www.inkscape.org/
[13] World Wide Web Consortium (W3C) http://www.w3.org/
[14] Scalable Vector Graphics (SVG) http://www.w3.org/Graphics/SVG/
[15] Extensible Markup Language (XML) http://www.w3.org/XML/
[16] XML Document Object Model (DOM) http://www.w3.org/DOM/
[17] W3C Schools – Online Tutorials http://www.w3schools.com/default.asp [18] XML Parser http://www.w3schools.com/xml/xml_parser.asp
[19] Expat XML Parser http://expat.sourceforge.net/
[20] Compare SANs to Alternate Technologies
http://www.brocade.com/san/evaluate/compare_san.jsp
[21] Barkakati, The Waite Group’s Turbo C Bible, 蔡明志譯, 松岡, 台北, 1992 [22] Robert Lafore, C Programming Using Turbo C++, 蔡明志譯, 松岡, 台北, 1992 [23] 施威銘, 80x86 MASM 6.x 組合語言實務, 旗標, 台北, 1996
Appendix A
External Storage system
In section 1.1 Overview of Storage Systems, we have introduced the overview of storage system. In this appendix, we explain the details of DAS (Direct Attached Storage), SAN (Storage Area Network), NAS (Network Attached Storage), and compare the difference between them. [20]
A.1 DAS (Direct Attached Storage)
Figure 30. DAS (Direct Attached Storage)
Historically, the standard way of connecting hosts to storage devices has been direct, one-to-one SCSI attachments. As more and more storage and servers are added to meet demands, a DAS environment can cause a proliferation of server and storage islands, creating
a huge management burden for administrators, as well as inefficient utilization of resources.
Data sharing in these environments is also severely limited.
A.2 SAN (Storage Area Network)
Figure 31. SAN (Storage Area Network)
The limitations and challenges of DAS are the reason many organizations today have
The limitations and challenges of DAS are the reason many organizations today have