- Email: [email protected]
Microcomputer project management
Microcomputer project management J Gallacher discusses the design life cycle of a microcomputer system and the tasks involved in its control
Management of o microcomputer's design life cycle is discussed. Importance is placed on the production of documentation for manufacture, testing and maintenance as part of the design process. In particular, this is necessitated by the high mean time between system failures. After some design definitions, the six stages of the design life cycle and the role of the project engineer ore discussed. A/so, the types of expertise required for microcomputer application are reviewed.
The task of microcomputer project management is to ascertain the user's requirements and create a system to meet these requirements within certain cost and time restraints. This basically involves control of the system design process. Software will be the major consideration as it is the most significant cost component in a microcomputer system. A qualitative breakdown of total system costs is given in Figure 1. Lack of a generally accepted design methodology makes the design process a difficult subject to evaluate. Indeed, in general it is ill-understood and not only in its application to microcomputer software engineering. MAIN
Figure 1. Total systems costs
TASK
The main task in designing a microcomputer system is to produce a set of documents from which the manufacture, testing, commissioning and maintenance of the system may be carried out. A good set of documentation must enable the test engineer, maintenance technician or even the designer at a later date to understand the operation of the system by referring only to that documentation. Probability of failure of semiconductor electronics is very low, and very long periods of time, indeed several years, may pass between faults by which time no one can remember how the system is supposed to operate and the maintanence staff are totally dependent upon the documentation. Consequently, system design is not simply to engineer a system to meet a specification but also a discipline in presenting the system design documentation. Many able and creative designers find the constraints imposed by good design methodology, including work documentation, irksome. However their views must be sacrificed to the common good of producing a well proven and documented system. It is essential to have a conceptual understanding of'a complex activity in order to master its intricacies. Without such a framework one has only MicroprocessorSystems EngineeringLtd, Craigavon, Boltachan, Aberfeldy, PH15 2LB, UK
vol 5 no I jan/feb 1981
isolated facts and techniques whose interrelationship may be obscured. Design of microcomputer systems is such an activity. The number of techniques, tools, pieces of information and rules of thumb which must be dealt with are numerous. The time taken to master the activity of system design is measured in years of full time activity - if it can be mastered at all! It is possible to extract square roots or integrate simple equations without knowing much about the philosophy of mathematics, but it is doubtful if even a modest skill in system design can be acquired without a grasp of its philosophy. Before undertaking a study of microcomputer design methods it is important to understand the total context in which the design takes place and the fundamental nature of its components. Designing is an interesting human activity which eludes precise characterization because of its many forms and its complexity. Designing software has its own characteristics but it also shares much with design in other fields. It is interesting to consider some one-line definitions of design by various philosphers: a goal-directed problem-solving activity • relating product with situation to give satisfaction • performing a very complicated act of faith • an imaginative jump from present facts to future possibilities
•
0 1 4 1 - 9 3 3 1 / 8 1 / 0 1 0 0 1 9 - 4 $02.00 © 1981 IPC Business Press
19
DESIGN LIFE CYCLE It is now necessary to consider the stages in the microcomputer design life cycle. System design is a multilayered sequential process. The various stages do not have clear boundaries and the process is both iterative and inter active. The main interactive stage is in producing the requirements definition or project specification. At the beginning of the project the user has little knowledge of what a microcomputer system can do and the project design engineer has little understanding of the process to be controlled. However, between them they must produce as precise a definition of the system requirements as they can. In particular an operational flowsheet or pseudocode representation must be agreed. The main stages of the design life cycle can be set out as follows:
~3C 5C 2C IC
n-O 02 0,1 I
I
I
~ n tation
I
I
I
Unit test Sy~test Operation Phase
Figure 2. Cost o f delayed error detection
] Requirements analysis - the user discovers a requirement for which a microcomputer system seems to be the answer. The nature of the requirement is analysed and the outline of the type of system which would satisfy these needs is established 2 Requirements definition - functional descriptions of the system are developed, along with technical and economic constraints on its structure and resource usage. At this point the required accuracies, timing, etc. of the operations must be established 3 Project specification - this is the architectural design of the system. Working from the requirements definition an overall design of the system is devised which matches the underlying structure of the requirements. The parts of the system and their relationships, and the basic hardware and software are settled at this stage 4 Detailed design - the major parts of the design are now detailed. Precise specifications of instrumentation and actuator requirements are drawn up and compared with suppliers specifications. Field cabling requirements are assessed and decisions taken whether to have central or distributed control. Having decided these points it is then possible to define interface and central controlunit requirements. Hardware modules will be selected or designed and built. Detailed flowsheets will be drawn up. These should be to the level from which programming in a high level language can be implemented. They should stop short of the type of housekeeping programming details required in assembly language programming i.e. setting of flags, clearing of buffers, etc. Implementation - this is the physical realization of the design. It includes the testing of individual modules, the assembly of the modules into a complete system, programming, system testing and performance evaluation. 6 Maintenance - everything that happens after the system is commissioned is regarded as maintenance. This applies to software as much as to, or even more than, hardware. It covers the location and repair of bugs, addition of new functions, modification of existing functions, and addition of features originally in the design but never implemented. It is important to recognise certain things which have been left implicit. First, the stages outlined are temporal stages. Although they are named by the dominant activity of each stage, many activities may occur at each stage. Second, the differentiation between software design and total system design is not clear. In some applications most of the stages outlined above deal primarily with software design. In other applications the choice of hardware may be open. Third, an essential part of the design process is the deferment of
20
activities to their appropriate place. This implies deferring stage 4 (Detailed design) until stage 3 (Project specification) is complete and similarly deferring stage 5 (Implementation) until stage 4 is complete. It is a sad reflection on the history of software development that this kind of postponement requires special mention. In no other industry would tooling-up precede completion of the fundamental design. Failure to d~:fer implementation has proved to be a major cause of many of the more spectacular software failures. Figure 2 shows the relative cost of delayed error detection which further emphasises the need for the proper deferment of activities.
DESIGN CYCLE A C T I V I T I E S An informal system analysis is now given to further the under. standing of the structure of the development process. For each stage the primary inputs (I), outputs (0) and major operations (OP) are listed.
1
Requirementsanalysis I primitive needs, user problems O general requirements OP identification of major functions and restraints
2
Requirements definition I O
requirements, analysis of context specification of system functions, constraints and objectives OP conversion of needs into explicit functions, selection of constraints which are operational
3
Project specification I
specification of system functions, general context of desired system, knowledge of similar systems O structural description of system OP discovery of problem structure, identification of major parts of system, relationship between parts 4
Detailed design I structural description O drawings and flowsheets OP elaborations, choice of alternatives
5
Implementation I O
drawings and flowsheets manufacture and programming
OP coding, testing, debugging
microprocessors and microsystems
6
Maintenance I system, documentation O improved system OP debugging, redesign, reprogramming, enchancement
Traditionally 25% o~ project time has been spent on specification and design which has resulted in 50% of project time being spent on system debug and test. Increasingly detailed and better specification and design will result in a decrease in system test time. The overall project time will not reduce greatly but a much better system with a reducted maintenance commitment potential will be produced.
REQUIREMENTS SPECl FICATION It is now necessary to consider the all-important question of the requirements specification. Looking back a considerable number of computer projects associated with industrial applications were regarded as failures in the sense that objectives were not fully realized and costs and timescales were drastically overrun. The reasons for such failures could invariably be traced to inadequate specification, and project management and control. There are a number of requirements to which an adequate requirements specification must conform: • • • • • • • •
completeness consistency correctness testability unambiguity design freedom modularity readability
The goal of testability is most important yet is frequently overlooked. If there is a requirement which cannot be tested, then it might as well not be written. Likewise requirements must be feasible. Part of the problem of producing adequate requirements specifications has been the failure to separate the phases of requirements analysis and specification from the subsequent design phase. Requirements analysis must not trespass on design; that is, it must not make assumptions about the constitution of the system because it is the task of system design to deduce these from the specification which is the result of the requirements analysis. There are problems in separating require= ments specification and design in that not only are current methods and techniques somewhat limited but also the goal of a complete requirements specification may not be reasonable or possible in all circumstances. The system designer is thus poised on the horns of a dilemma: should he attempt the impossible (or at least improbable) of producing a complete specification before starting design? or should he compound the analysis and design stages and run the risk of producing a system which fails to meet requirements? The importance of a thorough requirements analysis and specification ultimately comes down to economic considerations. A recurrent theme is that the earlier an error is detected the less expensive it is to correct it. Perhaps part of the reluctance of industry to invest sufficient effort in the requirements analysis phase of a project is due to the amount of the investment compared With the amount of immediately visible return. The return on the investment may not be visible for a year or more:
vol 5 no I jan~feb 1981
An analysis of errors in requirements specifications has yielded the following data: unclear/ambiguous missing/incomplete i ncorrect/u ntestable/ overrestrictive out of scope inconsistent writing/typing
10% 20% 35% 15% 10% 10%
SYSTEM DESIGN PROCEDURE The procedure starts with the delegation of responsibility to a project engineer to define the problem and produce a specification. At this stage it is not possible to define a system in complete detail, and it may not even be desirable. The user is often much better off with general statements sufficient to enable suppliers to make proposals. In this way different approaches will be made which can often produce solutions not previously considered. The purpose of the proposal is to permit the user to select a supplier, System design therefore starts at the proposal stage. An appraisal of the specification must be made so that a proposal can be prepared using tried and proven hardware and software. Proven hardware is a must and proven software is highly desirable but of course much more difficult to arrange. It is therefore important that modular hardware design techniques and structured programming be used. In this way the system will comprise a number of individual blocks, each of known performance, such that when connected together the overall performance of the system can be predicted. This is essential in order that sufficient design can be carried out to ensure that the system performance can be achieved. The terms user, supplier and proposer, while implying different cempanies, can in practice be groups of engineers within a company manufacturing its own systems. In either case there is some procedure similar to that described, before the system designer can start the detailed design. The main task then is to produce a set of documentation and drawings from which the system can be built. Where possible, the same documents and drawings should enable the system to be maintained by other engineers; so often the system design is not clear to those who must follow on.
D OC U ME N TA TI ON For large systems in particular, and where a team of engineers is involved, the project specification is vital and is inherent in the system design task. Project specifications are more detailed than previous specifications and proposals. They vary in format not only with the size and scope of the project but with the user, since the project specification is produced to meet his requirements. A typical project specification begins with a section which describes the operation of the system in general terms. This will be followed by a section which covers the system design i.e. how the system operation is achieved. It is important to describe the control philosophy, particularly where there are optional methods of controlling the process which implies a hierarchy of control. This description should give a clear understanding of under which circumstances certain operators or plant devices have priority of control. This is the area of control which is peculiar to the particular application and the detailed knowledge of
21
which is always vested in the end user. This is usually followed by a hardware section which details all the equipment to be designed into the system. It should particularly include bought-in items. Data sheets and general arrangements drawings should be included in this section together with any mandatory codes of practice. The construction, finish and layout of panel and consoles, the environmental specification and the power distribution table should also be included. In computer-based systems there should also be a section on software. This section should include agreed flowsheets which are sufficiently detailed to ensure assessment of the correctness of the program. In this way, although the system may not do what the user expects it to do,it will be possible to check if it is doing what has been agreed.
for the system. In cases where the microprocessor is being used at circuit-design level, where software replaces circuitry, it is necessary to have sufficient understanding of assembly lanugage programming to determine if there are timing problems. It is not enough to write a program which carries out the required functions. The software must not only be correct but also reliable, maintainable and reusable. Maintenance of software is everything that is done after the system has been tested. It is impossible to prove at the time of test that software is 100% correct. Errors can lie dormant untifsome untoreseen operation or program modification brings them to light. Eliminating these bugs is maintenance. The use of structured programs and high level languages can mitigate these problems.
DESIGN EXPERTISE
FUTURE TRENDS
The ability to design a digital system requires the following main areas of expertise:
The future trend in digital systems will be the everincreasing use of computer-based systems. This applies particularly to the use of microcomputer systems which of course also leads to the use of distributed systems. The use of distributed systems will require attention to secure communications paths with a more widespread use of fibreoptic transmission. However, the main impact on system design will be the continuing growth in introduction of single-board microcomputers and single-chip microcomputers. The single-chip microcomputer is particularly suitable for embedded applications. Thus the system design task will contain an ever-expanding content of software. This will require that the system designer acquire an adequate knowledge of computer science and software engineering.
• understanding of control technology • experience of the range of hardware to be used • knowledge of the commercially available components and devices which are necessary to complete the system • applications experience of the project, or access to engineers who have this experience • sufficient knowledge of computer science and software engineering to propose, or at least understand, the algorithms and flowsheets required to define the application It is also necessary to have adequate knowledge and experience of the mini- or microcomputer and peripherals proposed
inlormaOon -ilPnvaa' an international journal covering the technical, legal and social issues of computer-based information systems and their use The journal is of interest to engineers, designers, analysts, data processing management, legal advisers, security managers, government officials and top management.
~------------------Further details and sample copy from: Christine Mullins, IPC Science and Technology Press Ltd., PO Box 63, Westbury House, Bury St., Guildford, Surrey GU2 5BH, England Telephone: 0483-31261. Please send me further details of INFORMATION PRIVACY Name
.
Organization and address
.
Annual subscription £48.00 ($124.80)
...._-------------------------------------------22
microprocessors and microsystems
Management of o microcomputer's design life cycle is discussed. Importance is placed on the production of documentation for manufacture, testing and maintenance as part of the design process. In particular, this is necessitated by the high mean time between system failures. After some design definitions, the six stages of the design life cycle and the role of the project engineer ore discussed. A/so, the types of expertise required for microcomputer application are reviewed.
The task of microcomputer project management is to ascertain the user's requirements and create a system to meet these requirements within certain cost and time restraints. This basically involves control of the system design process. Software will be the major consideration as it is the most significant cost component in a microcomputer system. A qualitative breakdown of total system costs is given in Figure 1. Lack of a generally accepted design methodology makes the design process a difficult subject to evaluate. Indeed, in general it is ill-understood and not only in its application to microcomputer software engineering. MAIN
Figure 1. Total systems costs
TASK
The main task in designing a microcomputer system is to produce a set of documents from which the manufacture, testing, commissioning and maintenance of the system may be carried out. A good set of documentation must enable the test engineer, maintenance technician or even the designer at a later date to understand the operation of the system by referring only to that documentation. Probability of failure of semiconductor electronics is very low, and very long periods of time, indeed several years, may pass between faults by which time no one can remember how the system is supposed to operate and the maintanence staff are totally dependent upon the documentation. Consequently, system design is not simply to engineer a system to meet a specification but also a discipline in presenting the system design documentation. Many able and creative designers find the constraints imposed by good design methodology, including work documentation, irksome. However their views must be sacrificed to the common good of producing a well proven and documented system. It is essential to have a conceptual understanding of'a complex activity in order to master its intricacies. Without such a framework one has only MicroprocessorSystems EngineeringLtd, Craigavon, Boltachan, Aberfeldy, PH15 2LB, UK
vol 5 no I jan/feb 1981
isolated facts and techniques whose interrelationship may be obscured. Design of microcomputer systems is such an activity. The number of techniques, tools, pieces of information and rules of thumb which must be dealt with are numerous. The time taken to master the activity of system design is measured in years of full time activity - if it can be mastered at all! It is possible to extract square roots or integrate simple equations without knowing much about the philosophy of mathematics, but it is doubtful if even a modest skill in system design can be acquired without a grasp of its philosophy. Before undertaking a study of microcomputer design methods it is important to understand the total context in which the design takes place and the fundamental nature of its components. Designing is an interesting human activity which eludes precise characterization because of its many forms and its complexity. Designing software has its own characteristics but it also shares much with design in other fields. It is interesting to consider some one-line definitions of design by various philosphers: a goal-directed problem-solving activity • relating product with situation to give satisfaction • performing a very complicated act of faith • an imaginative jump from present facts to future possibilities
•
0 1 4 1 - 9 3 3 1 / 8 1 / 0 1 0 0 1 9 - 4 $02.00 © 1981 IPC Business Press
19
DESIGN LIFE CYCLE It is now necessary to consider the stages in the microcomputer design life cycle. System design is a multilayered sequential process. The various stages do not have clear boundaries and the process is both iterative and inter active. The main interactive stage is in producing the requirements definition or project specification. At the beginning of the project the user has little knowledge of what a microcomputer system can do and the project design engineer has little understanding of the process to be controlled. However, between them they must produce as precise a definition of the system requirements as they can. In particular an operational flowsheet or pseudocode representation must be agreed. The main stages of the design life cycle can be set out as follows:
~3C 5C 2C IC
n-O 02 0,1 I
I
I
~ n tation
I
I
I
Unit test Sy~test Operation Phase
Figure 2. Cost o f delayed error detection
] Requirements analysis - the user discovers a requirement for which a microcomputer system seems to be the answer. The nature of the requirement is analysed and the outline of the type of system which would satisfy these needs is established 2 Requirements definition - functional descriptions of the system are developed, along with technical and economic constraints on its structure and resource usage. At this point the required accuracies, timing, etc. of the operations must be established 3 Project specification - this is the architectural design of the system. Working from the requirements definition an overall design of the system is devised which matches the underlying structure of the requirements. The parts of the system and their relationships, and the basic hardware and software are settled at this stage 4 Detailed design - the major parts of the design are now detailed. Precise specifications of instrumentation and actuator requirements are drawn up and compared with suppliers specifications. Field cabling requirements are assessed and decisions taken whether to have central or distributed control. Having decided these points it is then possible to define interface and central controlunit requirements. Hardware modules will be selected or designed and built. Detailed flowsheets will be drawn up. These should be to the level from which programming in a high level language can be implemented. They should stop short of the type of housekeeping programming details required in assembly language programming i.e. setting of flags, clearing of buffers, etc. Implementation - this is the physical realization of the design. It includes the testing of individual modules, the assembly of the modules into a complete system, programming, system testing and performance evaluation. 6 Maintenance - everything that happens after the system is commissioned is regarded as maintenance. This applies to software as much as to, or even more than, hardware. It covers the location and repair of bugs, addition of new functions, modification of existing functions, and addition of features originally in the design but never implemented. It is important to recognise certain things which have been left implicit. First, the stages outlined are temporal stages. Although they are named by the dominant activity of each stage, many activities may occur at each stage. Second, the differentiation between software design and total system design is not clear. In some applications most of the stages outlined above deal primarily with software design. In other applications the choice of hardware may be open. Third, an essential part of the design process is the deferment of
20
activities to their appropriate place. This implies deferring stage 4 (Detailed design) until stage 3 (Project specification) is complete and similarly deferring stage 5 (Implementation) until stage 4 is complete. It is a sad reflection on the history of software development that this kind of postponement requires special mention. In no other industry would tooling-up precede completion of the fundamental design. Failure to d~:fer implementation has proved to be a major cause of many of the more spectacular software failures. Figure 2 shows the relative cost of delayed error detection which further emphasises the need for the proper deferment of activities.
DESIGN CYCLE A C T I V I T I E S An informal system analysis is now given to further the under. standing of the structure of the development process. For each stage the primary inputs (I), outputs (0) and major operations (OP) are listed.
1
Requirementsanalysis I primitive needs, user problems O general requirements OP identification of major functions and restraints
2
Requirements definition I O
requirements, analysis of context specification of system functions, constraints and objectives OP conversion of needs into explicit functions, selection of constraints which are operational
3
Project specification I
specification of system functions, general context of desired system, knowledge of similar systems O structural description of system OP discovery of problem structure, identification of major parts of system, relationship between parts 4
Detailed design I structural description O drawings and flowsheets OP elaborations, choice of alternatives
5
Implementation I O
drawings and flowsheets manufacture and programming
OP coding, testing, debugging
microprocessors and microsystems
6
Maintenance I system, documentation O improved system OP debugging, redesign, reprogramming, enchancement
Traditionally 25% o~ project time has been spent on specification and design which has resulted in 50% of project time being spent on system debug and test. Increasingly detailed and better specification and design will result in a decrease in system test time. The overall project time will not reduce greatly but a much better system with a reducted maintenance commitment potential will be produced.
REQUIREMENTS SPECl FICATION It is now necessary to consider the all-important question of the requirements specification. Looking back a considerable number of computer projects associated with industrial applications were regarded as failures in the sense that objectives were not fully realized and costs and timescales were drastically overrun. The reasons for such failures could invariably be traced to inadequate specification, and project management and control. There are a number of requirements to which an adequate requirements specification must conform: • • • • • • • •
completeness consistency correctness testability unambiguity design freedom modularity readability
The goal of testability is most important yet is frequently overlooked. If there is a requirement which cannot be tested, then it might as well not be written. Likewise requirements must be feasible. Part of the problem of producing adequate requirements specifications has been the failure to separate the phases of requirements analysis and specification from the subsequent design phase. Requirements analysis must not trespass on design; that is, it must not make assumptions about the constitution of the system because it is the task of system design to deduce these from the specification which is the result of the requirements analysis. There are problems in separating require= ments specification and design in that not only are current methods and techniques somewhat limited but also the goal of a complete requirements specification may not be reasonable or possible in all circumstances. The system designer is thus poised on the horns of a dilemma: should he attempt the impossible (or at least improbable) of producing a complete specification before starting design? or should he compound the analysis and design stages and run the risk of producing a system which fails to meet requirements? The importance of a thorough requirements analysis and specification ultimately comes down to economic considerations. A recurrent theme is that the earlier an error is detected the less expensive it is to correct it. Perhaps part of the reluctance of industry to invest sufficient effort in the requirements analysis phase of a project is due to the amount of the investment compared With the amount of immediately visible return. The return on the investment may not be visible for a year or more:
vol 5 no I jan~feb 1981
An analysis of errors in requirements specifications has yielded the following data: unclear/ambiguous missing/incomplete i ncorrect/u ntestable/ overrestrictive out of scope inconsistent writing/typing
10% 20% 35% 15% 10% 10%
SYSTEM DESIGN PROCEDURE The procedure starts with the delegation of responsibility to a project engineer to define the problem and produce a specification. At this stage it is not possible to define a system in complete detail, and it may not even be desirable. The user is often much better off with general statements sufficient to enable suppliers to make proposals. In this way different approaches will be made which can often produce solutions not previously considered. The purpose of the proposal is to permit the user to select a supplier, System design therefore starts at the proposal stage. An appraisal of the specification must be made so that a proposal can be prepared using tried and proven hardware and software. Proven hardware is a must and proven software is highly desirable but of course much more difficult to arrange. It is therefore important that modular hardware design techniques and structured programming be used. In this way the system will comprise a number of individual blocks, each of known performance, such that when connected together the overall performance of the system can be predicted. This is essential in order that sufficient design can be carried out to ensure that the system performance can be achieved. The terms user, supplier and proposer, while implying different cempanies, can in practice be groups of engineers within a company manufacturing its own systems. In either case there is some procedure similar to that described, before the system designer can start the detailed design. The main task then is to produce a set of documentation and drawings from which the system can be built. Where possible, the same documents and drawings should enable the system to be maintained by other engineers; so often the system design is not clear to those who must follow on.
D OC U ME N TA TI ON For large systems in particular, and where a team of engineers is involved, the project specification is vital and is inherent in the system design task. Project specifications are more detailed than previous specifications and proposals. They vary in format not only with the size and scope of the project but with the user, since the project specification is produced to meet his requirements. A typical project specification begins with a section which describes the operation of the system in general terms. This will be followed by a section which covers the system design i.e. how the system operation is achieved. It is important to describe the control philosophy, particularly where there are optional methods of controlling the process which implies a hierarchy of control. This description should give a clear understanding of under which circumstances certain operators or plant devices have priority of control. This is the area of control which is peculiar to the particular application and the detailed knowledge of
21
which is always vested in the end user. This is usually followed by a hardware section which details all the equipment to be designed into the system. It should particularly include bought-in items. Data sheets and general arrangements drawings should be included in this section together with any mandatory codes of practice. The construction, finish and layout of panel and consoles, the environmental specification and the power distribution table should also be included. In computer-based systems there should also be a section on software. This section should include agreed flowsheets which are sufficiently detailed to ensure assessment of the correctness of the program. In this way, although the system may not do what the user expects it to do,it will be possible to check if it is doing what has been agreed.
for the system. In cases where the microprocessor is being used at circuit-design level, where software replaces circuitry, it is necessary to have sufficient understanding of assembly lanugage programming to determine if there are timing problems. It is not enough to write a program which carries out the required functions. The software must not only be correct but also reliable, maintainable and reusable. Maintenance of software is everything that is done after the system has been tested. It is impossible to prove at the time of test that software is 100% correct. Errors can lie dormant untifsome untoreseen operation or program modification brings them to light. Eliminating these bugs is maintenance. The use of structured programs and high level languages can mitigate these problems.
DESIGN EXPERTISE
FUTURE TRENDS
The ability to design a digital system requires the following main areas of expertise:
The future trend in digital systems will be the everincreasing use of computer-based systems. This applies particularly to the use of microcomputer systems which of course also leads to the use of distributed systems. The use of distributed systems will require attention to secure communications paths with a more widespread use of fibreoptic transmission. However, the main impact on system design will be the continuing growth in introduction of single-board microcomputers and single-chip microcomputers. The single-chip microcomputer is particularly suitable for embedded applications. Thus the system design task will contain an ever-expanding content of software. This will require that the system designer acquire an adequate knowledge of computer science and software engineering.
• understanding of control technology • experience of the range of hardware to be used • knowledge of the commercially available components and devices which are necessary to complete the system • applications experience of the project, or access to engineers who have this experience • sufficient knowledge of computer science and software engineering to propose, or at least understand, the algorithms and flowsheets required to define the application It is also necessary to have adequate knowledge and experience of the mini- or microcomputer and peripherals proposed
inlormaOon -ilPnvaa' an international journal covering the technical, legal and social issues of computer-based information systems and their use The journal is of interest to engineers, designers, analysts, data processing management, legal advisers, security managers, government officials and top management.
~------------------Further details and sample copy from: Christine Mullins, IPC Science and Technology Press Ltd., PO Box 63, Westbury House, Bury St., Guildford, Surrey GU2 5BH, England Telephone: 0483-31261. Please send me further details of INFORMATION PRIVACY Name
.
Organization and address
.
Annual subscription £48.00 ($124.80)
...._-------------------------------------------22
microprocessors and microsystems