Conventional Software Framework for MMIs of Storage Systems

We analyze conventional software framework for MMIs of storage systems, and generalize four layers: 1) MMI Program, 2) Management API, 3) Driver Layer, and 4) Embedded Firmware.

Here is a short example to describe the relationship between these layers. The end-users use the MMI Program to display the information or configuration of storage systems.

Before MMI Program displays these data, it calls the functions of Management API to get the particular data, and then it arranges the data into the display screen. Management API is a function library, and its functions can submit management commands to get the information or set the configuration of storage systems. These commands will pass to Driver Layer because this is the software layer to transfer commands to hardware devices. In the internal side of storage systems, Embedded Firmware handles commands from host side and response them with particular results.

Figure 9 illustrates the Conventional Software Framework for MMIs of Storage Systems with these four layers.

Figure 9. Conventional Software Framework for MMIs of Storage Systems

We describe these four layers in the following paragraphs.

1) MMI Program: According to MMI specifications, programmers implement MMI programs for particular utilities. For instance, they implement the MMI program in assembly language for Booting Utility, C language for Pre-OS Utility, Java for Web-based Utility, etc.

These MMI Programs call Management API to get information or change the setting of storage systems. For Embedded Utility and LCD Panel of storage systems, there are related applications embedded in firmware side.

2) Management API: Management API is a library with many functions for utilities to get information, fetch strings, or change the setting of storage systems. For example, function MngApi_GetCtrlInfo( ) can get controller information, and function MngApi_GetPdInfo( ) can get physical drive information. The other functions can set logical driver’s cache policy, etc.

First, the Booting Utility of storage systems includes basic functions only, so it usually uses minimal Management API. Second, the Pre-OS Utility is similar to Booting Utility, but it includes some advanced functions, and needs some additional Management API for these advanced functions. Third, the Web-based Utility includes full functions of storage systems, and of course, it uses full Management API of storage systems.

3) Driver Layer: Driver provides the capability to submit commands to hardware devices. Usually Management API submits a set of management commands, or called IOCTRL (IO Control) commands, to Driver Layer. No matter BIOS / EFI driver, Pre-OS driver or OS driver will pass these commands to the embedded firmware of storage systems.

4) Embedded Firmware: In the internal side of storage systems, there are embedded operating system and firmware core running. Firmware core handles commands from host side, transfer data to the buffer of Management API by DMA (Direct Memory Access), and return the status of commands to host drivers. For Embedded Utility and LCD Panel of storage systems, the related applications are running in embedded OS also.

Before MMI programs display the information of storage systems, they must call the functions of Management API to get the wanted information. Management API provides many functions for MMI programs and submits management commands to firmware by passing through the Driver Layer to get data. Driver passes management commands to firmware and returns the status of commands for Management API. Embedded firmware takes the responsibility to handle management commands and take the actions for them. For example, Embedded Firmware collects information of adapter controller or hard disk drives, or changes the setting of disk array, etc.

Chapter 3

System Design and Implementation

In this chapter, we describe the design and implementation of the Visual MMI Development for Storage Systems, and derive the Generic Software Framework for the MMI Generation of Storage Systems.

3.1 Visual MMI Development for Storage Systems

In this section, we design the model of Visual MMI Development for Storage Systems. This model uses similar concept of Visual-Based User Interface Construction Methodology, MMI designers use visual authoring tool to compose MMIs, and programmers write functional and other programs separately. Figure 10 illustrates this concept.

Figure 10. The Concept of Visual MMI Development for Storage Systems

However, the difference between Visual-Based UI Construction Methodology and Visual MMI Development for Storage Systems is the output of the Visual Authoring Process.

In the previous methodology, Visual Authoring Tool generates MMI program, and programmer binds functions from functional library to MMI program and generate MMI applications.

We change the output of the Visual Authoring Process becomes MMI data, and let Generic MMI Engine to manipulate this MMI data directly. This change is due to the consideration on some limitations for MMI utilities of storage systems. With this change, we can implement the Generic MMI Engine for various environments.

Figure 11 illustrates the framework of Visual MMI Development for Storage Systems.

Figure 11. The Framework of Visual MMI Development for Storage Systems

This framework includes the following major parts:

1) Visual Authoring Tool: MMI designers use the Visual Authoring Tool to compose wanted MMIs according to MMI requirement documents. During implementation, we choose Inkscape as this tool. Please refer to section 3.3.1 Visual Authoring Tool -- Inkscape.

2) SVG Files: These files are the output of Visual Authoring Tool. We use the file format in SVG (Scalable Vector Graphics) that is a standard language to describe two-dimensional graphics and graphical applications in XML (Extensible Markup Language).

Please refer to section 3.3.2 SVG Files.

3) Template SVG Files: These files are the SVG files with templates of MMI elements.

To speed up the development of MMIs, we can create these files for MMI designers first. All SVG files can be previewed in some web browsers, e.g. Firefox.

4) SVG Parser: This parser can parse the SVG structure, and obtain required information from SVG files. It invokes some functions of XML parser. Please refer to section 3.3.3 SVG Parser.

5) MMI Data: The output data of SVG Parser is MMI Data. It is also the results of Visual Authoring Process. Generic MMI Engine can manipulate the MMI Data directly.

Please refer to section 3.3.4 MMI Data.

6) Generic MMI Engine: This is the kernel component of Visual MMI Development for Storage Systems. It needs the Management API and OS Dependent API to accomplish the functionalities of target MMI application. Please refer to section 3.3.5 Generic MMI Engine.

7) Management API: This API (Application Program Interface) is depended on the features of storage systems, and it provides functions to manage underlying storage devices.

MMI programmers have to program these functions according to functional requirement documents, and Generic MMI Engine will invoke these functions.

8) OS Dependent API: Generic MMI Engine requires some functional APIs but they are OS dependent. For instance, it needs Input API to get the input of keyboard or mouse, and Display API to display the MMIs to the monitor screen of computers. We separate the OS dependent code to OS Dependent API, and let the implementation of Generic MMI Engine become more easily for various environments.

9) Target MMI Application: After MMI designers compose MMIs with Visual Authoring Tool, save them as SVG files, and use SVG Parser to transform SVG files to MMI data, we can generate target MMI application with MMI data, Generic MMI Engine, Management API and OS Dependent API.

To use the model of Visual MMI Development for Storage Systems, we describe its flow in the following steps:

Step 1) MMI designers use Visual Authoring Tool to compose wanted MMIs according to MMI requirement documents

Step 2) Save the results of Visula Authoring Tool as SVG Files.

Step 3) To speed up the development of MMIs, we can create Template SVG Files for MMI designers.

Step 4) For developers or customers, they can preview these SVG Files in web browsers.

Step 5) MMI programmers add additional information in SVG Files.

Step 6) Use SVG Parser to transform SVG Files to MMI Data.

Step 7) MMI programmers program related functions in Management API according to functional requirement documents.

Step 8) Generate the target MMI applications with MMI Data, Generic MMI Engine, Management API and OS dependent API.

3.2 Generic Software Framework for the MMI Generation of Storage Systems

The conventional software framework for the MMI generation of storage systems lacks of the support of a visual authoring system. We therefore incorporate a visual authoring system into the software framework for MMIs of storage systems. The incorporated Visual Authoring and MMI Engine are shown in figure 12. We call the new software framework as Generic Software Framework for the MMI Generation of Storage Systems, since it can be used to generate Man Machine Interfaces of many storage systems.

Figure 12. Generic Software Framework for the MMI Generation of Storage Systems

There are also four layers in Generic Software Framework for the MMI Generation of Storage Systems: 1) Visual Authoring Process, 2) Generic MMI Engine, 3) Driver Layer, and 4) Embedded Firmware. We introduce the new layers:

1) Visual Authoring Process: MMI designers use Visual Authoring Tool to compose each MMI according to the MMI requirement specification for particular utility. The authoring tool is visualized and very user-friendly. After save the results in SVG files and use SVG Parser to parse these files, we can get the MMI data for Generic MMI Engine at the end of Visual Authoring Process. For instance, MMI designers use Visual Authoring Tool to compose the MMIs of Booting Utility and Pre-OS Utility, and then generate the Booting MMI Data and Pre-OS MMI Data.

2) Generic MMI Engine: Programmers do not need to write any MMI programs, but they have to program the related functions for MMIs. We design the Generic MMI Engine as common code, and it invokes these MMI related functions. This engine also cooperates with the Management API of storage systems. The design of Generic MMI Engine is OS independent, and we separate the OS dependent functions to OS Dependent APIs. This design is helpful to implement utilities in various environments.

The 3) Driver Layer and 4) Embedded Firmware are the same as the ones in the conventional software framework for MMIs of storage systems.

After MMI designers finish the Visual Authoring Process and programmers write the related functions for MMIs, we can come out the particular utility for storage systems with the MMI Data, Generic MMI Engine, and Management API. This utility still needs Driver Layer to pass commands to Embedded Firmware of storage systems.

3.3 Implementation of Visual MMI Development for Storage Systems

To implement the Visual MMI Development for Storage Systems, we must consider five key components: 1) Visual Authoring Tool – Inkscape, 2) SVG Files, 3) SVG Parser, 4) MMI Data, and 5) Generic MMI Engine.

The first phase of Visual MMI Development for Storage Systems is Visual Authoring Process. We illustrate this procedure in figure 13, and describe the details of this process in the following sections.

Figure 13. Visual Authoring Process

3.3.1 Visual Authoring Tool -- Inkscape

In our implementation, we choose Inkscape [12] as Visual Authoring Tool. Inkscape is an open source vector graphics editor, with capabilities similar to Illustrator, Freehand, CorelDraw, or Xara X using the W3C [13] standard Scalable Vector Graphics (SVG) file format. Supported SVG features include shapes, paths, text, markers, clones, alpha blending, transforms, gradients, patterns, and grouping. Inkscape also supports Creative Commons meta-data, node editing, layers, complex path operations, bitmap tracing, text-on-path, flowed text, direct XML editing, and more. It imports formats such as JPEG, PNG, TIFF, and others and exports PNG as well as multiple vector-based formats.

The main goal of Inkscape is to create a powerful and convenient drawing tool fully compliant with XML, SVG, and CSS standards. Therefore, it is very suitable for the Visual Authoring Process of Visual MMI Development for Storage Systems.

In figure 14, it is a snapshot of the Inkscape usage.

Figure 14. Visual Authoring Tool -- Inkscape

MMI designers can use the Graphic Tools, Canvas, and Layers Manager of Inkscape to implement MMIs for storage systems. To simplify and formalize the implementation of MMIs for storage systems, we use Graphic Tools to create rectangles and texts only, and put them in the Canvas area. To compose more complex vector graphics, MMI designers can use the Layer Manager to overlap many layers of graphics.

On the other hand, MMI programmers can use the XML Editor of Inkscape to modify SVG files conveniently. They can modify the name, attributes of SVG elements, and define the relationship between lots of SVG elements, or add the related functions in the functional or other programs into SVG elements.

Figure 15 illustrates one SVG file in plan text and the XML Editor of Inkscape. We recommend MMI programmers to use the XML Editor of Inkscape to add information in SVG files.

Figure 15. Edit SVG File in the XML Editor of Inkscape

To implement man machine interfaces by Visual Authoring Process, MMI designers or programmers are free to learn the SVG language. MMI designers use Inkscape to compose wanted MMI graphics and save them to the files in SVG format. When programmers want to modify the SVG files, they do not need to handcraft the SVG file in plain text. On the contrary, programmers can use the XML editor of Inkscape to edit SVG file easily and user-friendly.

3.3.2 SVG Files

SVG (Scalable Vector Graphics) [14] is a language for describing two-dimensional graphics and graphical applications in XML (Extensible Markup Language) [15]. XML is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.

SVG is used in many business areas including Web graphics, animation, user interfaces, graphics interchange, print and hardcopy output, mobile applications and high-quality design. It has two parts: an XML-based file format and a programming API for graphical applications. Key features include shapes, text and embedded raster graphics, with many different painting styles. It supports scripting through languages such as ECMAScript and has comprehensive support for animation.

SVG is a royalty-free vendor-neutral open standard developed under the W3C Process.

It has strong industry support; Authors of the SVG specification include Adobe, Agfa, Apple, Canon, Corel, Ericsson, HP, IBM, Kodak, Macromedia, Microsoft, Nokia, Sharp and Sun Microsystems. SVG viewers are deployed to over 100 million desktops, and there is a broad range of support in many authoring tools.

SVG builds upon many other successful standards such as XML (SVG graphics are text-based and thus easy to create), JPEG and PNG for image formats, DOM for scripting and interactivity, SMIL for animation and CSS for styling.

SVG is interoperable. The W3C release a test suite and implementation results to ensure conformance. Applications of SVG in industry are graphics platform for mobile phone, embedded system and print industry, web applications, design and interchange, GIS (Geographic Information Systems) and mapping, etc.

We adopt SVG files as the inter-media of Visual Authoring Process because SVG has above advantages. For example, we can preview the MMI in SVG files by web browser, and MMI programmers can add more information about MMI programs into SVG files conveniently. Furthermore, we can apply the functionality of XML parser to implement the specific SVG Parse very easily for the SVG files of MMI.

To simplify the implementation, we use three SVG elements, Layer, Rect and Text, to implement the MMI elements for storage systems. Please refer to the relationship between SVG elements and MMI elements in the following table. Using the same SVG element, we define one or more MMI elements with different attributes sot that we can manipulate them very conveniently in Generic MMI Engine.

Table 2. Implement MMI Elements by SVG Elements

SVG Elements MMI Elements

Layer Screen, Layer

Rect Rect, Edge

Text Text, Title, Head, Cont, Navi, Msg, Node

1) Using SVG Layer element to implement Screen, Layer MMI elements: The Layer Manger of Inkscape can control SVG Layer element to display or hide, free-to-modify or lock-up. We define Screen element to compose the base screen layout, and Layer element to place one menu and its related components, e.g. some items in this menu, or help messages for it.

2) Using SVG Rect element to implement Rect, Edige MMI elements: The rectangle in SVG graphics can be solid or hollow rectangles. We use solid rectangle to define Rect MMI element that is used for menu’s body and shadow, and hollow rectangle to define Edge MMI element that is the edge or border of menu’s body.

3) Using SVG Text element to implement Text, Title, Head, Cont, Navi, Msg, Node MMI elements: The SVG Text element has many attributes, like font size or color. We use the same font size for all text MMI elements. Nevertheless, we define many text MMI elements with different colors. They are used for different purposes: The Text MMI element is a common string and can be used in base screen layer. The Title MMI element is used for the title of base screen or menus. The Head MMI element is used for the head of items in menus.

The Cont MMI element is used for the content of items in menus. The Navi MMI element is used for the string on Navigation Bar. The Navigation Bar is the row between screen title and canvas and it can show the path of current menus. The Msg MMI element is used for the string on Message Bar. The Message Bar is the lowest row in screen and it can display the message for current menu. The latest and important MMI element, Node, can carry the information to child menu and the related function to take actions, but MMI programmers must add the child menu and related function for each Node manually.

3.3.3 SVG Parser

After using Inkscape to create SVG files, we need a parser to parse SVG structure and obtain required information from SVG files. We call this parser as SVG Parser. Before describe the SVG parser, we introduce the concept of XML DOM (Document Object Model) first.

In the right part of figure 16, it is a simple XML in plain text. This XML describes a bookstore with a couple of books.

Figure 16. XML in Plain Text

Each book has four elements: title, author, year and price. For example, first book’s title is “Everyday Italian” in English language, because its attribute is lang=”en”, author is

“Giada De Laurentiis”, year is 2005, price is 30.00. In the left part of figure 16, there is a tree to describe the hierarchy of that XML. It is very easy to understand compared with the plain text format.

Figure 17 illustrates a using example of XML DOM (Document Object Model) for the above XML of bookstore.

Figure 17. XML DOM

The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can

The Document Object Model is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents. The document can be further processed and the results of that processing can