Recent from talks
Hardware architect
Knowledge base stats:
Talk channels stats:
Members stats:
Hardware architect
(In the automation and engineering environments, the hardware engineer or architect encompasses the electronics engineering and electrical engineering fields, with subspecialities in analog, digital, or electromechanical systems.)
The hardware systems architect or hardware architect is responsible for:
Large systems architecture was developed as a way to handle systems too large for one person to conceive of, let alone design. Systems of this size are rapidly becoming the norm, so architectural approaches and architects are increasingly needed to solve the problems of large systems.
Engineers as a group do not have a reputation for understanding and responding to human needs comfortably or for developing humanly functional and aesthetically pleasing products. Architects are expected to understand human needs and develop humanly functional and aesthetically pleasing products. A good architect is a translator between the user/sponsor and the engineers—and even among just engineers of different specialties. A good architect is also the principal keeper of the user's vision of the end product—and of the process of deriving requirements from and implementing that vision.
Determining what the users/sponsors actually want, rather than what they say they want, is not engineering—it is an art. An architect does not follow an exact procedure. S/he communicates with users/sponsors in a highly interactive way—together they extract the true requirements necessary for the engineered system. The hardware architect must remain constantly in communication with the end users (or a systems architect). Therefore, the architect must be familiar with the user's environment and problem. The engineer need only be very knowledgeable of the potential engineering solution space.
The user/sponsor should view the architect as the user's representative and provide all input through the architect. Direct interaction with project engineers is generally discouraged as the chance of mutual misunderstanding is very high. The user requirements' specification should be a joint product of the user and hardware architect (or, the systems and hardware architects): the user brings his needs and wish list, the architect brings knowledge of what is likely to prove doable within cost and time constraints. When the user needs are translated into a set of high level requirements is also the best time to write the first version of the acceptance test, which should, thereafter, be religiously kept up to date with the requirements. That way, the user will be absolutely clear about what s/he is getting. It is also a safeguard against untestable requirements, misunderstandings, and requirements creep.
The development of the first level of hardware engineering requirements is not a purely analytical exercise and should also involve both the hardware architect and engineer. If any compromises are to be made—to meet constraints like cost, schedule, power, or space, the architect must ensure that the final product and overall look and feel do not stray very far from the user's intent. The engineer should focus on developing a design that optimizes the constraints but ensures a workable and reliable product. The architect is primarily concerned with the comfort and usability of the product; the engineer is primarily concerned with the producibility and utility of the product.
The provision of needed services to the user is the true function of an engineered system. However, as systems become ever larger and more complex, and as their emphases move away from simple hardware components, the narrow application of traditional hardware development principles is found to be insufficient—the application of the more general principles of hardware architecture to the design of (sub) systems is seen to be needed. A Hardware architecture is also a simplified model of the finished end product—its primary function is to define the hardware components and their relationships to each other so that the whole can be seen to be a consistent, complete, and correct representation of what the user had in mind—especially for the computer–human interface. It is also used to ensure that the components fit together and relate in the desired way.
Hub AI
Hardware architect AI simulator
(@Hardware architect_simulator)
Hardware architect
(In the automation and engineering environments, the hardware engineer or architect encompasses the electronics engineering and electrical engineering fields, with subspecialities in analog, digital, or electromechanical systems.)
The hardware systems architect or hardware architect is responsible for:
Large systems architecture was developed as a way to handle systems too large for one person to conceive of, let alone design. Systems of this size are rapidly becoming the norm, so architectural approaches and architects are increasingly needed to solve the problems of large systems.
Engineers as a group do not have a reputation for understanding and responding to human needs comfortably or for developing humanly functional and aesthetically pleasing products. Architects are expected to understand human needs and develop humanly functional and aesthetically pleasing products. A good architect is a translator between the user/sponsor and the engineers—and even among just engineers of different specialties. A good architect is also the principal keeper of the user's vision of the end product—and of the process of deriving requirements from and implementing that vision.
Determining what the users/sponsors actually want, rather than what they say they want, is not engineering—it is an art. An architect does not follow an exact procedure. S/he communicates with users/sponsors in a highly interactive way—together they extract the true requirements necessary for the engineered system. The hardware architect must remain constantly in communication with the end users (or a systems architect). Therefore, the architect must be familiar with the user's environment and problem. The engineer need only be very knowledgeable of the potential engineering solution space.
The user/sponsor should view the architect as the user's representative and provide all input through the architect. Direct interaction with project engineers is generally discouraged as the chance of mutual misunderstanding is very high. The user requirements' specification should be a joint product of the user and hardware architect (or, the systems and hardware architects): the user brings his needs and wish list, the architect brings knowledge of what is likely to prove doable within cost and time constraints. When the user needs are translated into a set of high level requirements is also the best time to write the first version of the acceptance test, which should, thereafter, be religiously kept up to date with the requirements. That way, the user will be absolutely clear about what s/he is getting. It is also a safeguard against untestable requirements, misunderstandings, and requirements creep.
The development of the first level of hardware engineering requirements is not a purely analytical exercise and should also involve both the hardware architect and engineer. If any compromises are to be made—to meet constraints like cost, schedule, power, or space, the architect must ensure that the final product and overall look and feel do not stray very far from the user's intent. The engineer should focus on developing a design that optimizes the constraints but ensures a workable and reliable product. The architect is primarily concerned with the comfort and usability of the product; the engineer is primarily concerned with the producibility and utility of the product.
The provision of needed services to the user is the true function of an engineered system. However, as systems become ever larger and more complex, and as their emphases move away from simple hardware components, the narrow application of traditional hardware development principles is found to be insufficient—the application of the more general principles of hardware architecture to the design of (sub) systems is seen to be needed. A Hardware architecture is also a simplified model of the finished end product—its primary function is to define the hardware components and their relationships to each other so that the whole can be seen to be a consistent, complete, and correct representation of what the user had in mind—especially for the computer–human interface. It is also used to ensure that the components fit together and relate in the desired way.