Welcome to Integrated Systems Lab.
This is a space for exploring how hardware, embedded systems, IoT, and software can be brought together to build practical engineering solutions.
I’ll be sharing projects I’m working on, technical experiments, system development, things I’m learning, and lessons from the process of turning ideas into working systems.
The focus is on building, integrating, testing, and learning—from individual components to complete systems.
If you’re interested in embedded systems, IoT, automation, software integration, and engineering technology, follow along.
Build. Integrate. Learn.
This is a space for exploring how hardware, embedded systems, IoT, and software can be brought together to build practical engineering solutions.
I’ll be sharing projects I’m working on, technical experiments, system development, things I’m learning, and lessons from the process of turning ideas into working systems.
The focus is on building, integrating, testing, and learning—from individual components to complete systems.
If you’re interested in embedded systems, IoT, automation, software integration, and engineering technology, follow along.
Build. Integrate. Learn.
Let’s start our first learning series with something we interact with more often than we might realize: identity verification.
Think about your normal day.
You unlock your phone with your fingerprint or face. You log in to a computer with a password. You use a bank app to access your account. You enter a PIN at an ATM. You tap a card to enter a building.
Although these systems are used in very different situations, they all have something in common: the system needs to know who is requesting access.
At that moment, a simple question is being asked:
That question leads us to identity verification.
In this series, we’ll break down how these systems actually work — starting with the basic idea of verifying an identity, then moving into authentication, authorization, access control, system architecture, and how these concepts come together in real systems.
Let’s understand the system first, then build our way into the technology behind it
Think about your normal day.
You unlock your phone with your fingerprint or face. You log in to a computer with a password. You use a bank app to access your account. You enter a PIN at an ATM. You tap a card to enter a building.
Although these systems are used in very different situations, they all have something in common: the system needs to know who is requesting access.
At that moment, a simple question is being asked:
“Are you really who you claim to be?”
That question leads us to identity verification.
In this series, we’ll break down how these systems actually work — starting with the basic idea of verifying an identity, then moving into authentication, authorization, access control, system architecture, and how these concepts come together in real systems.
Let’s understand the system first, then build our way into the technology behind it
Now that we’ve seen how common identity verification is in everyday life, let’s look at what actually happens.
Identity verification is simply the process of checking whether the identity someone presents matches a registered identity.
For example, when you use a fingerprint to access your phone, the system doesn’t just see a fingerprint and open the device. It captures the information, processes it, and compares it with the information already registered.
The same basic idea can be found in banking, computers, access-control systems, and many other applications.
A simplified process looks like this:
Person → Presents identity → System collects information → System verifies → Result
The result might be:
Match → Identity verified
or
No match → Identity not verified
But there is something important to understand here.
Identity verification answers: “Who are you?”
Identity verification is simply the process of checking whether the identity someone presents matches a registered identity.
For example, when you use a fingerprint to access your phone, the system doesn’t just see a fingerprint and open the device. It captures the information, processes it, and compares it with the information already registered.
The same basic idea can be found in banking, computers, access-control systems, and many other applications.
A simplified process looks like this:
Person → Presents identity → System collects information → System verifies → Result
The result might be:
Match → Identity verified
or
No match → Identity not verified
But there is something important to understand here.
Identity verification answers: “Who are you?”
Authentication: Proving Your Identity
We’ve seen what identity verification means. Now let’s look at another term that often comes with it: authentication.
When you log into your computer, open a banking app, or unlock your phone, the system needs to determine whether the person using the credential is actually the person associated with it.
That is the basic idea of authentication.
For example, you enter a password. The system checks it against the registered information. Or you provide a fingerprint, and the system compares it with the registered biometric information.
So, in simple terms:
Identification → Who do you claim to be?
Authentication → Can the system verify that claim?
But even after the system verifies your identity, there is still another question:
What are you allowed to access?
That takes us to authorization.
We’ve seen what identity verification means. Now let’s look at another term that often comes with it: authentication.
When you log into your computer, open a banking app, or unlock your phone, the system needs to determine whether the person using the credential is actually the person associated with it.
That is the basic idea of authentication.
For example, you enter a password. The system checks it against the registered information. Or you provide a fingerprint, and the system compares it with the registered biometric information.
So, in simple terms:
Identification → Who do you claim to be?
Authentication → Can the system verify that claim?
But even after the system verifies your identity, there is still another question:
What are you allowed to access?
That takes us to authorization.
Authorization: What Are You Allowed to Do?
Imagine that you have successfully logged into an organization's system.
The system knows who you are.
But does that mean you can access everything?
Not necessarily.
This is where authorization comes in.
Authorization determines what an authenticated user is permitted to access or do.
For example, in a computer system:
A normal user might access their own files.
An administrator might also be allowed to manage users and system settings.
The important distinction is:
Authentication → Who are you?
Authorization → What are you allowed to do?
These two processes work together, but they solve different problems.
And when we need to enforce these permissions in a real environment, we enter the world of access control.
Imagine that you have successfully logged into an organization's system.
The system knows who you are.
But does that mean you can access everything?
Not necessarily.
This is where authorization comes in.
Authorization determines what an authenticated user is permitted to access or do.
For example, in a computer system:
A normal user might access their own files.
An administrator might also be allowed to manage users and system settings.
The important distinction is:
Authentication → Who are you?
Authorization → What are you allowed to do?
These two processes work together, but they solve different problems.
And when we need to enforce these permissions in a real environment, we enter the world of access control.
Access Control: Turning the Decision Into Action
So far, we have asked two questions:
Who are you?
and
What are you allowed to access?
Access control is where the system uses that information to make and enforce an actual access decision.
Think about entering a restricted building.
You present your credential.
The system verifies your identity.
It checks whether you have permission to enter.
Then it makes a decision:
Access granted
or
Access denied
The same basic idea exists in digital systems such as computers, applications, databases, and banking platforms.
A simplified flow is:
User → Identification → Authentication → Authorization → Access Decision → Action
The interesting part is that a real access-control system needs more than this basic flow.
It may need user management, administration, data storage, feedback, event records, system control, and reliable operation.
At this point, we are no longer looking at a single feature.
We are looking at a complete system.
So far, we have asked two questions:
Who are you?
and
What are you allowed to access?
Access control is where the system uses that information to make and enforce an actual access decision.
Think about entering a restricted building.
You present your credential.
The system verifies your identity.
It checks whether you have permission to enter.
Then it makes a decision:
Access granted
or
Access denied
The same basic idea exists in digital systems such as computers, applications, databases, and banking platforms.
A simplified flow is:
User → Identification → Authentication → Authorization → Access Decision → Action
The interesting part is that a real access-control system needs more than this basic flow.
It may need user management, administration, data storage, feedback, event records, system control, and reliable operation.
At this point, we are no longer looking at a single feature.
We are looking at a complete system.
Bringing the System Together
Let’s put everything we have learned together.
We started with identity verification.
Then we looked at authentication and authorization.
Finally, we saw how access control uses these processes to make an actual decision.
A simplified system can be viewed like this:
User
↓
Identity Input
↓
Verification / Authentication
↓
Authorization
↓
Access Decision
↓
Grant or Deny Access
Around this core process, a real system can include:
User Management • Administration • Data Storage • Feedback • Event Records • System Control
This is where system engineering becomes important.
The challenge isn't just making one part work. The challenge is connecting the different parts so they work together as one usable system.
And this is exactly where we can move from learning to something we have actually built.
Let’s put everything we have learned together.
We started with identity verification.
Then we looked at authentication and authorization.
Finally, we saw how access control uses these processes to make an actual decision.
A simplified system can be viewed like this:
User
↓
Identity Input
↓
Verification / Authentication
↓
Authorization
↓
Access Decision
↓
Grant or Deny Access
Around this core process, a real system can include:
User Management • Administration • Data Storage • Feedback • Event Records • System Control
This is where system engineering becomes important.
The challenge isn't just making one part work. The challenge is connecting the different parts so they work together as one usable system.
And this is exactly where we can move from learning to something we have actually built.
From Concept to a Real System — BiTec Access V1
In our previous posts, we explored how identity verification, authentication, authorization, and access control work.
Now, let’s see those concepts in a real system.
Meet BiTec Access V1 — our first product version for identity verification and access management.
How the concept becomes a working system:
1️⃣ Identify
The user presents an identity using an available authentication method.
2️⃣ Authenticate
The system checks whether the presented identity matches a registered user.
3️⃣ Authorize
The system determines whether that user is allowed to access.
4️⃣ Control
The system makes the access decision — allowed or denied.
5️⃣ Respond
The system gives feedback and displays the relevant user information.
So what we learned theoretically:
Identity → Authentication → Authorization → Access Control
is now working together as a complete physical product.
These images show some of the actual interactions with BiTec Access V1, including card-based and fingerprint authentication.
And this is the important part:
In the next posts, we'll look deeper into how BiTec Access V1 is structured and how the different parts work together.
Learn → Understand → Build → See it working.
In our previous posts, we explored how identity verification, authentication, authorization, and access control work.
Now, let’s see those concepts in a real system.
Meet BiTec Access V1 — our first product version for identity verification and access management.
How the concept becomes a working system:
1️⃣ Identify
The user presents an identity using an available authentication method.
2️⃣ Authenticate
The system checks whether the presented identity matches a registered user.
3️⃣ Authorize
The system determines whether that user is allowed to access.
4️⃣ Control
The system makes the access decision — allowed or denied.
5️⃣ Respond
The system gives feedback and displays the relevant user information.
So what we learned theoretically:
Identity → Authentication → Authorization → Access Control
is now working together as a complete physical product.
These images show some of the actual interactions with BiTec Access V1, including card-based and fingerprint authentication.
And this is the important part:
The goal was not simply to build individual functions, but to bring the concepts together into one working system.
In the next posts, we'll look deeper into how BiTec Access V1 is structured and how the different parts work together.
Learn → Understand → Build → See it working.
From Concept to a Real System — BiTec Access V1
In our previous posts, we learned about identity verification, authentication, authorization, and access control.
So far, we have been looking at these ideas separately.
Now let's put them together.
This is BiTec Access V1, our first product version for identity verification and access management.
Think about what happens when someone wants to enter a restricted area:
1️⃣ The person presents their identity
For example, using a card or fingerprint.
2️⃣ The system verifies the identity
It checks the information against a registered user.
3️⃣ The system checks permission
Being a registered user does not automatically mean the person has access.
4️⃣ The system makes a decision
Access allowed ✓ or Access denied ✕
5️⃣ The system responds
It gives feedback and, when appropriate, displays the user's information.
So the concepts we learned earlier:
are no longer just concepts.
They are working together inside a real product.
The photos show BiTec Access V1 in operation, including card and fingerprint-based authentication.
The important part is not just that we built different functions.
We brought those functions together to create one working system.
In our previous posts, we learned about identity verification, authentication, authorization, and access control.
So far, we have been looking at these ideas separately.
Now let's put them together.
This is BiTec Access V1, our first product version for identity verification and access management.
Think about what happens when someone wants to enter a restricted area:
1️⃣ The person presents their identity
For example, using a card or fingerprint.
2️⃣ The system verifies the identity
It checks the information against a registered user.
3️⃣ The system checks permission
Being a registered user does not automatically mean the person has access.
4️⃣ The system makes a decision
Access allowed ✓ or Access denied ✕
5️⃣ The system responds
It gives feedback and, when appropriate, displays the user's information.
So the concepts we learned earlier:
Identity → Authentication → Authorization → Access Control
are no longer just concepts.
They are working together inside a real product.
The photos show BiTec Access V1 in operation, including card and fingerprint-based authentication.
The important part is not just that we built different functions.
We brought those functions together to create one working system.
Forwarded from Teddy ...
This media is not supported in your browser
VIEW IN TELEGRAM
