Talk about the concept of automotive components from the perspective of hardware, software and system
Latest update time：2021-05-25
Reads：
When we discuss the decomposition and integration, subordination and mapping relationships of software, hardware, and functional levels, many concepts such as components, components, middleware, components, modules, systems, etc. will be involved.
Is it confusing? Very messy.
But if these concepts cannot be distinguished, a lot of problems will arise in the basic language of communication, which is not conducive to the entire product process. The first step in the process is to have a clear understanding of various concepts in order to find the context in the process of sorting out complex issues.
There are a few things you need to pay attention to in advance
-
Chinese is broad and profound. A word has different meanings in different dimensions. Many words have the same meaning in different dimensions. They must be clearly identified.
-
When looking at something, it must have multiple angles, and the reason why the logic is confusing is because we discuss an issue without first locking in an angle. More importantly, you often have to switch to look at something from multiple angles, and finally sort out one thing clearly.
-
Component is the most useful and least useful concept. It is often a concept created from one perspective to sort out internal logic. It is recursive and does not consider scale. When viewed from a fixed perspective, the largest concept (such as assembly) is often clarified, and the smallest concept (such as parts) is clarified to lock the thinking scope of a perspective, and the middle parts can be called components. appear, so it is important to focus on identification and not to confuse them. It has only internal meaning from any perspective and has no external meaning.
01
Hardware dimension
First, let’s sort it out from the perspective of hardware. Hardware is simply something that can be seen and touched, which gives it many unique perspectives (manufacturing, assembly, mechanical movement, electrical connection)
Parts are the basic units that make up a machine, such as a nut. Generally, those that can be independently manufactured (stamping, casting, etc.) are called parts. The concept of a joint is similar. It consists of two or more parts and is connected together by a non-detachable connection method (such as riveting, welding, etc.). It can also be used as a basic unit at a higher level.
From the perspective of hardware mechanical motion, there is often the concept of components
Components refer to various motion units assembled from various types of parts. The components in the mechanism can be divided into frames, prime movers, driven parts, etc. They are independent movement units and can be considered as the basic unit of mechanical movement.
The organization is composed of individual components. The mechanism is an important part of the machine. One of the main functions of the mechanism is to transmit and convert motion.
From the perspective of hardware assembly, there are often concepts of components and components (assembly)
Component is a concept between parts and components. It can be understood as a combination of parts that satisfies a basic function.
Components are things that are structurally combined to work together to complete higher-level assembly requirements. They are composed of several components, parts and parts. A component is the smallest unit in the assembly line assembly process, and car companies often call it an assembly.
02
software dimension
Then if we start from the software perspective, software is something that is invisible and intangible. Although strictly speaking, code is considered a thing, but more importantly, there will be some specific perspectives on the logic of software. Especially in design, programming and redesign based on reusability. There is a big difference between the software perspective and the hardware perspective.
From the perspective of software code files (programming), there are several visible components
A module (compilation unit) is a collection of program statements (that is, a collection of program codes and data structures) that can be individually named and independently complete certain functions. It has two basic characteristics: external characteristics and internal characteristics. External characteristics refer to the interface between the module and the external environment; internal characteristics refer to the characteristics of the internal environment of the module, that is, the local data and program code of the module. It can be simply understood as the smallest unit of software.
The concept of component has been explained before. It is an intermediate concept and is also called a large module (component). The concept of sub-module (component) is recursive and its properties are the same as a module. When different components are assembled to form larger components, it is actually
software integration
. There are also some special variants, such as plug-ins, which are also a type of component (module), but have strong independent functional attributes.
When the code is actually handed over to people to write, it is often organized from this perspective.
From the perspective of software reusability, there are several concepts in design thinking
Component here is an object (Object). It is called a component in C++, a component in Delphi, and a control in VB. Components are simple encapsulations of data and methods that can be logically assembled by generating instances.
Component is reusable software that can be used to construct other software. It can be an encapsulated object class, class tree, some functional module software, etc. Components are divided into component classes and component instances. By giving the parameters of the component class, instances are generated, and corresponding application software is constructed through the assembly and control of the instances. The logic is similar to that of components, but the components are often more complex.
Design pattern (Pattern) is actually a methodology for solving a certain type of problem. If you summarize the methods for solving certain types of problems to a theoretical level, that is a pattern. Each pattern describes a recurring problem in our environment and then describes the core of the solution to that problem. This way, you can use existing solutions countless times without having to repeat the same work.
Patterns are designed for reuse.
A framework is a semi-finished product of a certain application that you can choose to complete your own system. Frameworks are generally mature and continuously upgraded software. On a deeper level, they also represent certain constraints and have specific applicable scenarios.
Components are code reuse, design patterns are design reuse, and frameworks are somewhere in between, with some code reuse and some design reuse. If you want to make an analogy, software reusability is a kind of "hardware assembly" in thinking.
From the perspective of software design, architecture is the most important concept. It is the systematic organization of the software system and the sum of decisions on system issues such as the interfaces, behavior patterns, and collaboration relationships of the components that make up the system. Software architecture is a series of related abstract patterns used to guide the design of various aspects of large software systems. If you know the UML language, it starts from different perspectives of software systems and defines 10 types of diagrams such as class diagrams, object diagrams, package diagrams, state diagrams, activity diagrams, sequence diagrams, communication diagrams, component diagrams, and deployment diagrams. A diagram represents a more detailed perspective on design, and each perspective has some subordinate and combinatorial definitions. I won’t go into details here.
In the implementation phase,
these abstract concepts are transformed into code modules and components
. For example, the design of a class or object in a class diagram will directly become a minimal software module. Of course, in most cases design and development do not necessarily map on one dimension. A brief summary of the relationship between design and development:
-
Structure + algorithm = module (or program)
-
Adjustment of logical relationships between modules = design pattern
-
Multiple design patterns, multi-module design based on several UML dimensions = architecture
Between software and hardware, due to certain reusability requirements, several important "components" are produced, which must be specially explained, including middleware, operating systems and database systems.
It often unifies the underlying complexity (including hardware and operating system itself) to provide support for the reuse of pure software logic.
03
system dimension
Finally, starting from functional design or other abstract purposes (security, performance, etc.) that are independent of software and hardware, there are concepts such as related items, systems, subsystems, components, etc.
These are often perspectives derived from the different demands of users. This perspective is usually taken from two matching perspectives. One is a pure system perspective, and the other is a division language that is suitable for the purpose.
Here we start from the perspective of functional safety and see what the specific logic is. In fact, the system design from the product perspective is also the same.
Starting from a pure system perspective
The concept of system (subsystem), for example, the human body is composed of eight major systems such as the motor system and the nervous system. You can understand that the human body is a system, and the motor system and nervous system are its subsystems. Systems often have clear inputs (perceptrons), processing (controllers), and outputs (executors). However, it must be noted that not a subsystem must have supporting independent hardware and software. It is often a complex system. mapping relationship.
Hardware part or software unit is the smallest unit, but what should be noted here is the minimum granularity of software or hardware that needs to be understood during the entire analysis process. It is not a physical concept.
Like other perspectives, component is an intermediate concept, something that is non-system level, non-basic, and has logical and technical separation.
From the perspective of functional safety description
The related item (Item) is the scope of a safety problem, which can be a single multiple functions or a single multiple systems. It is the input of functional safety hazard analysis and risk identification (HARA), and ultimately produces functional safety goals, and further Functional safety concept.
Element is a functional element that needs to describe the necessary functional safety requirements during the functional safety concept stage and assign these safety requirements to the system's functional elements. Can be any sub-unit of an item.
04
Summarize
Engineers engaged in the research and development of autonomous vehicles often switch back and forth between several concepts during the communication process. In addition to expanding their knowledge, the most important thing is to confirm the perspective of a concept and start thinking from this perspective. , and are used to transforming one thing from one perspective to another.
Read the original text and follow the author on Zhihu
京公网安备 11010802033920号