Millions of desktop PCs are manufactured every year; however, billions of embedded computer systems are also manufactured every year. For example, top of the range BMW cars contain over 150 dedicated embedded systems.

Following are the major characteristics of embedded systems,

• Dedicated to specific tasks
• Real-time constraints
• Cost sensitive
• Power sensitive
• Short design times
• Harsh operating environments
• Fail-safe operations

Following are the major challenges faced while designing embedded system,

• What is the optimum balance between hardware and software?
  • How much “hardware” do we need?
  • How much “software” do we need?
• How do we meet operational deadlines?
• How do we minimise power consumption?
• How do we design for upgradeability?
• How do we convince people that the system works properly?

Following are the steps involved in a typical design procedure for the embedded systems

• Capture and analyze the functional and non-functional requirements
• Develop a precise specification of the system functions
• Develop the overall system architecture
• Partition into “hardware” and “software” components
• Implement the hardware and software components. Reuse existing components where appropriate
• Integrate the components into a working system. Iterate the design process until the required working system has been produced

Embedded System is often used interchangeably with Real-time System, due to the real-time constraints involved in almost all the embedded systems. Real-time Embedded Systems are typically monitoring and/or control systems. The external environment (system or machine) is often termed the Controlled System. The Real-time Embedded System (including its hardware/OS) is known as the Controlling System. The real-time embedded systems include following additional characteristics.

• Concurrency - Simultaneous Processing
• Timeliness - Respond to events in short time
• Dependability - Failure of RTES maybe expensive/dangerous
• Interface with non-standard hardware – Due to dedicated hardware devices for performance gain

Real-time Embedded Systems (RTES) typically performs three categories of activity. Data acquisition – gathers data about the controlled system. Control system – analyse the data and determine the action the system should take. Human-Computer Interaction - receives commands and provides feedback to user if there is one.

]]> http://sajidsiraj.wordpress.com/2008/10/17/introduction-to-embedded-systems/feed/ 0 sajidsiraj http://sajidsiraj.wordpress.com/2008/10/03/guidelines-for-it-projects/ http://sajidsiraj.wordpress.com/2008/10/03/guidelines-for-it-projects/#comments Fri, 03 Oct 2008 01:16:02 +0000 Sajid Siraj http://sajidsiraj.wordpress.com/?p=34 ]]> Following are some of the suggested guidelines for the IT Projects:

• Decisions should not be made solely by a centralized administration, as they do not possess in-depth knowledge of organizational processes.

• The system specifications should exactly meet the business requirements. And the technology solution should also meet the system specifications.

• Do not replace humans with IT, use IT to assist them. The professional employees should be motivated and encouraged to participate and they should not feel that they will lose jobs due to IT.

• New, unproven technologies must be avoided.

• User involvement is not only a prerequisite for decisions concerning the prioritizing of requirements and the allocation of resources; it is also required for decisions concerning design.

• Hire the necessary expertise instead of learning everything yourself or asking the staff who is already engaged in other tasks.

• Issues concerning integration of devices and potential disturbance to the environment deserve careful consideration and should be a part of the design effort.

• Try to decompose project into smaller parts. Decomposition reduces the risks, as most of the problems get more localized and easy to handle. It makes the project more understandable for the non-technical members in the team.

• The process of standardization is extremely important for the design of systems. Not only the local processes but Interdepartmental processes and cooperation should also be standardized.

• Logic is important consideration but do consider the emotions of staff as well. Most projects come into socio-technical category so do not ignore the social perspective. Heal, console, encourage and listen to your team members

• Avoid duplication of effort by more than one department. Work should be performed where it makes the most sense.

• Extra checks, double-checks, and controls should be reduced. Keep them in a decent limit, this way everyone feels free while participating into the projects.

• Try to maintain a smooth communication, throughout the process, for everyone involved in IS development i.e. in-house staff, consultants, vendors etc.

• Enable sharing of information among departments, with appropriate security and access and within the limits of existing legislation.

• Do consider the previous experiences of similar types of projects. Learn from the failures that happened in the similar situation. This is necessary to broaden the view and avoid the same risks happening again.

• Be honest yourself and try to make the team works with honesty as well. Honesty is the key policy to make the projects successful.

Following are some of the reasons for the failure of many I.S. projects:

• Most of the time, clients do not clearly define their business needs and mapping them to functionalities required. Business Requirements should be properly extracted and correctly documented.

• There is a communication gap between the analyst and the customer. The analyst does not bother to communicate in the user’s language and fails to see that the technical schemes dissuade the user.

• Some projects fail due to the absence of version control system or any other kind of enforced record keeping. This record keeping is necessary during development and during maintenance as well.

• Saving time by shifting off issues to the next phase creates unrecoverable losses. A job half done always gives problems.

• Sometimes programmers wrongly accept the incomplete design in a hope that it will save time. This sometimes deviate the programmers from the right approach that should have been taken.

• Additional manpower is not always effective. It sometimes decreases the productivity. If one woman can produce a baby in nine months, nine women cannot produce a baby in one month.

• When managers fail to provide timely, adequate and properly trained resources, their projects generally fail.

• When executives push for unrealistic schedules, the project either will be late in delivering a working product or will produce a product that doesn’t work.

• If the software developers are asked to work overtime and it is unpaid in the schedule baseline, then developers lose their interest inside the project.

• Sometimes, managers knowingly omit some tasks from the budget & schedule, considering them low-priority. This sometimes leads to a disaster and it is realized afterwards that low-priority tasks were in fact not that low.

• If developers keep on doing last minute changes in the project, then such changes are left untested and appear on the ground when it is too late.

• There are many projects that inherently require updates and changes in their delivered products. It can be a failure if no practice is done to handle changes systematically to maintain its integrity over time.

• There are lots of errors and bugs usually undiscovered when same people are doing design and coding, or coding and testing.

• Lots of projects fail due to an unneeded complexity introduced in the design or implementation.

• Some of the projects are trusted solely on one person. Such hero-based projects are vulnerable to the failure.

• Projects that don’t plan for handling risks are hit by sudden surprises and can end up losing the client.

References:

[1] H. Winklhofer, “Organizational Change as a Contributing Factor to IS Failure”, Proceedings of the 34th Hawaii International Conference on Systems Sciences, January 2001, IEEE Computer Society, Los Alamitos

[2] Kurt R. Linberg, Software developer perceptions about software project failure: a case study, Journal of Systems and Software, Volume 49, Issues 2-3, 30 December 1999, Pages 177-192.

[3] S. Flowers, Software Failure: Management Failure. Amazing Stories and Cautionary Tales, Wiley, Chichester, New York, (1996), ISBN 0 171-95113-7

[4] William A. Yasnoff, How to Cause Information Technology Disasters, http://faculty.washington.edu/ocarroll/infrmatc/managing/howto/index.htm

[5] David J. Smith FBCI, Business Continuity Management: Good Practise Guidelines, The Business Continuity Institute, 2002, http://www.thebci.org

[6] Jari Vanhanen. Improving configuration mangement processes of a software product, Master’s Thesis, Helsinki University of Technology, December 1997.

[7] Paul Beynon-Davies. Human error and information systems failure: the case of the London ambulance service computer-aided dispatch system project. University of Glamorgan, Pontypridd CF37 1DL, Wales, UK

[8] Martin Neil, Are software failures deterministic?, Information and Software Technology, Volume 39, Issue 3, March 1997, Pages 217-219.

[9] Chris Johnson, Forensic software engineering: are software failures symptomatic of systemic problems?, Safety Science, Volume 40, Issue 9, December 2002, Pages 835-847.