The Hindu Business Line : `Engineers at work'

For a taste of product design, just step into this room. It's full of programmers and hardware engineers busy designing an intelligent heating and air-conditioning control system.

LET'S step into a room full of programmers and hardware engineers who are busy designing a new intelligent heating and air-conditioning control system, the first of which uses "a stand-alone intelligent thermostat that has an LCD output, three control buttons, four direction buttons, power LED, alarm LED, and internal temperature management and monitoring capabilities", as Oliver Bailey explains in Embedded Systems Design, from Wiley Dreamtech (www.wileydreamtech.com) .

Well, this is no classroom demonstration that you can turn away from, but real product design, though with "imaginative requests from a marketing department".

There's so much more to product design than a schematic, some microcontroller code, and a printed circuit board, reminds Ken Gracey in his foreword.

Designing the prototype is 90 per cent fun and 10 per cent work, and you can swap these two to bring a product to market, he'd add.

At the end of reading the book, "you'll have experience with three different microcontrollers, two different Ethernet controllers, and three different USB interfaces, three different compilers and user interface builders, and five different embedded compilers and languages," assures the introduction.

Meanwhile, the engineers are busy with three products, viz. one, with RS-232 port built-in to use the device from a desktop computer; two, a USB or Universal Serial Bus instead, that "allows a single host system to control multiple units and also allows the device to function as a data-acquisition system to be used for the monitoring and control of multiple rooms or floors within a building from a single PC"; and three, an Ethernet interface to allow the device to be connected to a LAN, so as to offer `one-to-many relationship'.

The marketing chaps aren't through with their demands. They want the device to have multi-platform support, across Windows, Unix and Linux.

The hardware group has worked on stand-alone electronic controls where all control was internal to the device, informs Bailey, and puts the engineers to work on a device that can be monitored and controlled from an outside source or from the keypad of the device.

Simultaneously, he engages the software group in the task of researching the cross-platform solutions that are available to make a single-source solution a reality; and also drives the systems group on to "the job of defining the device drivers to make the thermostat and PC talk".

If hardcore hardware always frightened, this is the book to try out, because Bailey communicates ideas in a friendly manner.

For example, in the discussion on data and control flow management, he writes: "When you develop an embedded system you have the operating system, user input, output, data handling, and everything else rolled into a single program that can range in size from 1 K to 64 K or so."

Like a general preparing the attack strategy, Bailey outlines two paths of device development. "The first makes use of off-the-shelf products for the prototype. Concurrent with prototype building will be a second development effort, building components of the unit from scratch. The end result will be a combination of off-the-shelf products and scratch-built pieces."

Ideal stuff for techies.

Performance management is a holistic task

MAXIMISE the performance and availability of network applications and the network infrastructure with APM or application performance management, writes Michael Hicks in Optimizing Applications on Cisco Networks, from Cisco (www.ciscopress.com) .

The performance of networked applications depends on complex interactions among applications, servers, and networks, he'd write in the introduction, explaining the continual struggle of network managers to keep pace with the demand for network resources, even as "new breeds of aggressive applications" hog available bandwidth.

Okay, we know that, but what's APM? It is both a business concept and an evolving technology, says Hicks.

"APM begins with organisations defining which of their business processes are critical." For example, in the case of Web pages, an organisation may define service objectives thus: "The Web page must be available and load within 15 seconds, 98 per cent of the time on weekdays and 90 per cent of the time on weekends."

Why should things be so specific? Because without clear-cut service objectives, management is meaningless and performance evaluation is irrelevant, points out the author.

"Most organisations do know when their network is up or down, but they don't really know what is happening on it in terms of application performance from an end-user perspective and whether a significant new application will perform acceptably once deployed over the network," notes Hicks, and that's something for you to check in your company!

Another point, that should interest accountants, is that increased investment may fail to improve performance.

"Simply throwing money at a problem is not always the answer - for example, upgrading the CPUs on a server to gain better performance will only have an effect if the CPU is the bottleneck." Performance management is a holistic task, please note.

In a chapter on understanding the business, the author guides you on how to compute TCO or total cost of ownership, taking into account the indirect costs of a network. He talks about `soft' costs involved in peer support and downtime. The former is "the time spent by users asking questions of other users and the time spent by users responding to questions such as, `How do I change my settings to use a different printer?'" and the latter is "the idle time spent by users because the network or their computer is down or slow".

Another chapter is about SLA or service level agreement, where you'd learn how to profile, that is, "define your required service levels based on both business and technical criteria", and also monitor performance, by collecting data "from key monitoring points to ensure that the required levels are actually met".

OSS is operational support system, you'd know from a chapter on monitoring. In every aspect of any OSS application, human factors are important, reminds Hicks.

"An application is a tool, a sophisticated machine designed to do a job for people. That job only gets done well if the machine is oiled properly and has the right materials to work with," he dins in an oft-ignored fact, doesn't he?

"For OSSs, the right materials are process definitions, interface requirements, and permissions that are necessary because people are part of the system," he'd declare. Aptly numbered chapter 10 is titled `when applications fail', and I'm sure you won't fail to read the other chapters too to know your network better!

Tailpiece

At the optical shop:

Customer: "I need special spectacles to read the tiny letters on my new mobile phone's keypad."

Shop attendant: "Try this new lenses-on-nose model, sir! It comes with a free offer of 10 lean sticks that you can attach to your fingers for easy keypad operation!"

Books2Byte@TheHindu.co.in

Article E-Mail :: Comment :: Syndication :: Printer Friendly Page

Stories in this Section
Dip in offing?

Watching the action

ICE in your mobile

Where do we go now?

A new cut for the CIO

Disabling autologon

Bringing up `Task Manager'

Deleting keylogger files

Don't stop dancing!

Sharing spectrum

`Engineers at work'

Cartoon