面向敏捷开发的嵌入式系统架构：分层模型

需积分: 0 101 浏览量更新于2024-07-18 收藏 6.59MB PDF 举报

"嵌入式系统架构对于敏捷开发至关重要，因为它们需要在快速变化的需求和迭代中保持稳定和高效。Mohsen Mirtalebi提出的层次化模型为实现这一目标提供了指导。这种架构方法强调模块化和分层设计，以促进敏捷开发中的可扩展性和灵活性。" 在设计高效的嵌入式系统以适应敏捷开发时，有几个关键知识点需要考虑： 1. **层次化设计**：基于层的架构模型将系统分解为多个独立的、功能相关的层，每个层都有明确的责任和接口。这种方法允许在不干扰其他层的情况下修改或更新单个层，从而提高敏捷性。 2. **模块化**：模块化是嵌入式系统设计的基础，它允许代码复用和独立测试。每个模块应具有清晰的输入、输出和接口，以支持敏捷开发中的快速迭代和重构。 3. **硬件-软件分离**：在敏捷环境中，硬件和软件通常需要并行开发。设计时，应确保硬件接口的抽象，使软件开发可以在硬件准备就绪之前进行，反之亦然。 4. **实时操作系统（RTOS）**：选择或定制适合敏捷开发的RTOS是关键。RTOS应支持多任务、调度策略以及实时性，以满足敏捷开发中频繁的部署和更新需求。 5. **敏捷方法论应用**：采用Scrum、Kanban等敏捷框架来管理嵌入式项目，可以提高响应速度，通过短周期的迭代和频繁的反馈，及时调整系统设计。 6. **测试驱动开发（TDD）**：在嵌入式系统中，测试是确保质量和敏捷性的核心。TDD鼓励先编写测试用例，然后编写满足这些测试的代码，确保系统的健壮性和可维护性。 7. **持续集成与持续交付（CI/CD）**：建立自动化构建和测试流程，以实现快速验证和部署。这有助于减少手动干预，加速反馈循环，并减少错误。 8. **软件定义的硬件**：在某些情况下，使用软件定义的硬件可以增加灵活性，使系统能在硬件不变的情况下适应软件变更。 9. **版本控制系统**：使用Git等版本控制工具，便于团队协作，跟踪代码更改历史，便于回溯和分支管理。 10. **文档与沟通**：尽管敏捷强调轻量级文档，但清晰的接口规范和团队间的有效沟通仍然至关重要，以确保所有成员对系统架构有共同理解。以上是嵌入式系统在敏捷开发中所涉及的关键知识点，通过这些方法，开发者可以构建出既能快速适应变化，又能保持稳定性能的嵌入式系统。

M. Mirtalebi, Embedded Systems Architecture for Agile Development,

https://doi.org/10.1007/978-1-4842-3051-0_1

CHAPTER 1

The History ofLayers

Architecture

What does developing a real-time system project have in common with a construction

project, from the project management perspective? Can we develop and manage both

projects with the same methodologies and tools? Some of you might think from a

project management standpoint, developing real-time or embedded systems should

not resemble developing a construction project. Although both might look similar

organizationally and share the same types of resources such as time, money, and people;

however, the fact that software has become an integral part of embedded systems will

significantly differentiate these two projects from each other. Now, this important

question arises: why is it that in many companies, both developments are called projects

and use the same project management tools? The answer to this question will go

beyond the boundaries of what the science of management can offer. This is because the

sciences involved with developing real-time systems are very new and are in a constant

state of change. Therefore the word “project” might carry a misleading connotation

when it’s used for developing embedded systems. But this misconception has deeper

roots than one might think. We all have seen many leaders in the embedded systems

industry still utilize the same tools and methods that a construction company uses in

developing their projects.

Nevertheless there are very valuable lessons in studying the construction projects,

not in the management methods that have been used for years but in their own schools

of thought. The construction industry has evolved through their thousands of years

of history. All in all, the traditional management tools can work for real-time systems

projects but in no way can one call this type of project management efficient for

developing mid- to large-size embedded systems. Through reading this book you will

realize how developing embedded systems are fundamentally different from any other

types of projects. To start off, let’s avoid the use of the term “project” temporarily as it

might misleadingly imply only a process. An embedded system development is not just

a process, it is a product integrated into a process. Although you might say a physical

building is considered a product but it is not, because it lacks manufacturing of the same

building in a volume of thousands of identical copies. Since a building is not a product,

therefore, the term “project” shouldn’t apply to embedded systems. If you want, you can,

but keep in mind, our embedded system development project implies the process and

product.

The fact that there will be thousands of copies of what you are making in the market

makes the concept of efficiency of grave importance. An efficient development method

results in an efficient product, and this translates directly to waste elimination, which

creates direct economic impacts on both our company and customers through our

process and products respectively. If we reduce the cost of development, our product

would become cost effective and more competitive in pricing. In return it will bring a

considerable amount of saving of costs to our customers. Combine efficiency and the

astronomical numbers of embedded systems used currently across the globe, and we

will come to the realization that the efficiency we intend to create will propagate to the

furthest corner of the earth. Now this is a true green process. So forget not about the

green products, but instead imagine your product will be the greenest of all. However,

for some reasons, the idea of green in the industry has been slowly becoming a concept

confined only to some promotional tools for marketing biodegradable materials in

products or environmentally compliant methods such as ISO14000.

Although the recent waves of the green movement in the waste management and

manufacturing process improvements are very good starting points for creating efficient

systems, the bulk of waste in resources happens during development of products of

any sorts. It is ironic that the term “green,” which would imply efficient should result

in lower costs; but rather it imposes additional compliance regulations by which the

manufacturers must assign budgets to maintain. This will result in higher developmental

costs and longer product time to market, which consequently results in higher product

prices defeating the purpose of being green. As we can see, a true green process results

in better economic impacts such as a lower finished cost of the product without

compromising the quality of the product. Therefore our concept of green runs a bit

deeper, and it starts from where the first idea of a product sparks; however, it doesn’t stop

there and it continues to bear fruit while it runs its entire course of product life cycle. The

Agile method of development is one way to reduce the waste since these methodologies

were initially created to specifically target waste; however there are two shortcomings in

Chapter 1 the history ofLayers arChiteCture

these frameworks. One is that most Agile methods are optimized for software products,

not embedded systems that are comprised of both software and hardware. Also,

embedded systems are produced in order to carry out critical applications where general

purpose computers are not to be trusted to perform the tasks; therefore saving costs is

not the main objective of creating these systems.

In other words, most real-time systems are mainly designed to carry out control

functions with critical applications. The Agile methods give waste elimination the

highest priority, which could make us happy about the efficiency portion, but they fail

to put enough emphasis on the robustness of the product. A good example of this is the

Microsoft products that are developed through Agile methods. Their numerous after-

release software patches and their daily software updates are evident that robustness is

not high on their list. We are not to blame one product over its lack of quality. What we

want to say is that, when there is not enough emphasis on one aspect of product or there

is so much of it on another aspect, people who follow those methods blindly might not

be able to put things in perspective. In addition, since in the span of development time

and also product life cycle the technology and hardware components can change, it is

very important to plan carefully ahead. While an Agile method empowers the project to

deal with short-term changes, it might make it easier for its followers to abandon long-

term plans for the product. The real consequence of this approach is that the importance

of architecture in product development will be devalued. As you can see later, the

product architecture plays a vital role in developing the embedded systems.

A project manager, in any type of project, from construction to hi-tech needs to

put several hats on during the life of the project. In a real-time system development

project, a manager needs to interface with different stakeholders and internal and

external customers at different phases of a project and needs to follow various life cycles

including project, product, and software life cycles. However, a project manager is hardly

a product architect. This is because most project managers are trained and skillful in the

art of management rather than designing a real-time system. This book is intended to

find the common aspects of various life cycles and introduce an inclusive methodology

that would cover them all under one umbrella with an emphasis on the necessary

amount of documentation. We are hoping that by the end by reading this book, if not

anything, at least your outlook will change toward real-time systems development.

Furthermore, this book is for the embedded system project architects who are aware

of steps involving developing a real-time system and not just the project. The detail of

how to become aware of the design steps is through systematic use of a tool called the

Chapter 1 the history ofLayers arChiteCture

requirement model. This new addition to what Agile methods seem to be lacking will

empower the project architects to create a robust architecture that would very well

address the criticality of a real-time system development while creating an efficient

process and product. The advantage of following an Agile method will break the never-

ending cycle of analysis-paralysis that most classical product development methods

suffer from. Nevertheless, we all know that the classical methods are the foundation

of the new methods; therefore, the ideas discussed here might be new but backward

compatible and are absolutely true to the traditional methods, especially the CPD

framework. Nevertheless, this book will not discuss the details of any design standards;

software and hardware testing methods such as white box, black box, or any hardware

development phase such as hardware alpha and beta prototyping; and manufacturing

bottlenecks such as functional and end-of-the line testing, but it will show you how to

utilize these methods and tools when you get to the different phases of development.

Nevertheless, if we look at the nature, there is a great lesson in it, that anything and

everything in nature happens for a reason. There is no beauty for the sake of only beauty.

Any vibrant or dull color and exotic or subtle shape carries a reason. It is useless to talk

about team structure and function if we don’t know the mission. A mission creates a

structure and a structure delivers a function. As Louise Henry Sullivan, the father of

skyscrapers and the founder of the school of organic architecture said, “Form Follows

Function.” This book is to show you how to build your processes around the product.

The New andtheOld

If you are coming from an Industrial Engineering background, you know that a simple

Gantt chart would never satisfy you if you are planning a project. This is because you

believe a project must have a baseline. But why don’t most project managers create

project baselines? It is because it’s a tedious job as you have to break down the project

to the units of work per person, which are called tasks, then you have to go on to load

all the tasks with resources that they are required to have their own work calendars.

Finally you have to apply the logical and temporal constraints to see how the tasks line

up, and at the end you have to level the resources by sliding the tasks in the schedule.

Therefore, creating a simple Gantt chart by no means is project planning and control.

Years later when I changed gears in my career and became an electrical engineer, to

my astonishment I saw the embedded system development projects were managed the

same way as a construction project was managed.

Chapter 1 the history ofLayers arChiteCture

However, considering the short history of electronics, software, and computer

engineering relative to other branches of engineering such as mechanical, chemical,

and civil, these new disciplines are still at their infancy stage with respect to work

standardization and offering best practices. Nevertheless, our modern manufacturing

and the backbone of our industries are built on the foundation of these new branches of

engineering. So the storyline goes like this: there are three young sheriffs in our town and

they are clueless.

Clash ofCultures

In every traditional development project there are two types of people. People who know

the product and people who know the project and hardly enough people who know the

product and project at the same time. People who know the product can tell you very

well what the product is comprised of. They can identify the sub-assemblies, modules,

and components; and they can break down the product into various functions. People

who know the project can arrange development and manufacturing work in such way

that product or concepts would come to life through the path of the least resistance.

However, both groups of people have one thing in common: they are concerned about

the constraints. Product-oriented crowds want to establish constraints and project-

oriented individuals want to avoid them. This brings up a very interesting phenomenon

in product development and manufacturing: the clash of cultures.

Clash ofThoughts

By definition, a project is a unique set of activities that a distinctive team of people carry

out only once. On the other hand, a process is what a fixed number of people do routinely.

With respect to constraints, projects want to remove the constraints and processes want

to solidify them. In classical project planning, the project manager starts drafting the

project with no constraints in mind, with the sort of 9-women-giving-birth-to- a-child-

in-a-month mentality. Therefore, ideally all project activities start at the same time and

continue concurrently. Consequently, the project managers don’t want any resource,

material, and budget constraints. However, in an engineering process everything is

diagonally opposing this view. Engineers, for example, want design reviews before

approvals, prototypes before releases, and so forth. This brings us to another fundamental

difference between processes and projects; let’s call it the clash of school of thoughts.

Chapter 1 the history ofLayers arChiteCture

剩余221页未读，继续阅读

西木米lyz

粉丝: 9
资源: 30

面向敏捷开发的嵌入式系统架构：分层模型

Embedded-Systems-Architecture:嵌入式系统体系结构，由Packt发布

Embedded_Systems_Architecture_2nd_Edition_正版高清英文版

Embedded Systems Architecture _ Explore architectural concepts _ Lacamera

用python遍历读取images文件夹里的图片和image_embeded文件夹里的图片，根据序号一一对应，用tensorflow库进行PSNR峰值信噪比计算

vscode配置linux内核

embeded usb2

unable to start embeded tomcat

Embeded Controller

embeded 深度学习

基于随机森林算法，通过One Vs Rest分类策略进行嵌入式embeded特征选择

最新资源