Smart bins and access control: how computerised eco-islands work

A computerised eco-island is not simply a bin with an electronic lock.

The system brings together a set of components with different functions: user identification, access control, opening management, event logging, fill-level monitoring, data communication and management software.

In some configurations, functions for measuring deposits, weighing during collection and integration with the operator’s information systems may also be added. An AMIU Puglia tender in 2024 for Bari, for example, provided for a lot of 14 underground eco-islands with access-controlled containers, depositor identification, fill verification, deposit detection, weighing during collection and an integrated IT system to monitor containers and the fleet.

The point to clarify is therefore the difference between controlling who may deposit, recording that a deposit has taken place, measuring how much was deposited and knowing how much space remains in the container.

These are different functions and must not be confused in the design.

What makes an eco-island “smart”?

From a technical point of view, the intelligence of the system does not lie in the container itself.

It is the digital infrastructure linking the deposit point to the management software that makes computerised management possible.

A configuration may include:

Function	What it detects or manages	Why it can be useful
User identification	Credential linked to the account	Establish who is authorised to deposit
Access control	Enabling or blocking the opening	Prevent unauthorised deposits
Event logging	Date, time, station, account or device	Build an operational history
Volumetric control	Maximum volume of a single deposit	Limit quantity or size of deposit
Weighing	Quantity deposited, when provided for	Support point measurement
Fill sensor	Container status or level	Support collection scheduling
Container identification	Unique bin ID	Link the container to the management system
Data communication	Transmission to central platform	Make events available to the operator
Management software	Data processing and display	Support monitoring and service organisation

A single island does not need to include all these functions.

The level of computerisation should be defined in relation to the service model the municipality or operator wants to implement.

On the Bunder Waste site at contenitori-interrati.it, configurations with access control and fill-level management are available; Bunder also states that its waste containers can be fitted with systems for access control and fill-level monitoring.

Access control: how does it work in practice?

Access control introduces an additional step between the user and the container.

In a traditional system:

In a controlled system:

Identification can take place via an electronic credential or another device compatible with the chosen architecture.

The basic logic is always the same: the opening normally remains inaccessible or locked and is enabled when the system recognises an authorised user.

An AMIU technical specification for smart underground containers expressly required that access normally be locked and that unlocking occur after identification of the enabled user. The same documentation provided for cards or access devices for users.

Access control can pursue different objectives

It should not be assumed that it always serves pay-as-you-throw charging.

It may be introduced to:

• limit deposits to authorised accounts;
• avoid indiscriminate use of the station;
• separate accounts or collection circuits;
• reduce the risk of improper deposits;
• log access events;
• prepare the system for subsequent measurement functions.

The objective must be defined before the technology.

An identification system installed without an associated management procedure produces data, but does not necessarily produce a measurable improvement in the service.

Identifying a user does not mean knowing how much they deposited

This is one of the most frequent misunderstandings.

Suppose Mario holds his card to the container opening.

The system can log:

But this data does not automatically mean:

To obtain a quantitative measurement, a system specifically designed to measure the deposit is required.

Measurement can be organised in different ways, depending on technology and service model: number of openings, authorised volume, volumetric devices, weighing or other modes defined in the project.

The AMIU Bari tender is an interesting example precisely because it separates the functions: the documentation refers to depositor identification and, at the same time, to weighing during collection.

For this reason a specification should avoid a generic formula such as “smart system” and instead describe which data the system must produce.

---

How controlled-opening deposit points work

A smart opening must coordinate at least three functions:

1. recognise the user’s request;
2. verify authorisation;
3. physically allow the deposit.

In the case of smart underground containers described in AMIU documentation, the openings are fitted with a conditional opening device and a user recognition system. For the non-recyclable fraction, a single-deposit volumetric control device was also provided.

This type of configuration also allows intervention on deposit quality.

For example, a volumetric limiter can prevent the introduction of bags or objects exceeding a given size, according to the configured setup.

The function is not necessarily tariff-related. It can also serve to avoid improper deposits or to make the waste flow more controllable.

---

Volumetric control: what does it measure?

Volumetric control operates at a different level from the bin fill sensor.

The first concerns the single deposit.

The second concerns the overall status of the container.

An AMIU technical specification for Bari provided, for non-recyclable waste, a three-dimensional volumetric device integrated in the opening, with a count of openings per account and limitation of the volume that can be deposited in each cycle. The same documentation linked this function both to the possible future use of pay-as-you-throw strategies and to control of the quality of deposited waste.

It is therefore useful to distinguish:

Control of the single deposit
How much or which volume can be introduced at that moment?

Container monitoring
How full is the container overall?

These are two different problems.

---

Fill sensors: how do they help the operator?

The fill sensor has a much simpler operational function to understand.

Its objective is to provide an estimate of the container status.

Instead of organising the collection round solely on the basis of a fixed calendar, the operator can use level data to see which stations require intervention.

The principle is:

Level monitoring is now also provided for in public projects dedicated to digitising collection. OpenCUP, for example, records a project by the Municipality of Lecco dedicated to technological solutions and collection containers fitted with fill and compaction sensors.

Public documents relating to territorial innovation projects also classify “smart bin” sensors among the technologies that can be used to monitor fill level in bins and litter bins.

The sensor does not automatically eliminate a scheduled collection round

This point is important.

Knowing the fill level allows better decisions only if the data is actually used by the operational system.

It is therefore necessary to define:

• who views the data;
• how an alarm is generated;
• which threshold is used;
• how the event enters planning;
• who decides to dispatch the vehicle;
• how emptying is recorded.

A sensor linked to a dashboard that nobody consults does not constitute a true optimisation system.

---

From sensors to software: the invisible part of the smart island

The station electronics are only the first level.

To work in practice, the system must transfer data to a platform capable at least of associating:

In more complex projects the following may be added:

• battery status;
• anomalies;
• opening status;
• opening events;
• container identification;
• station coordinates;
• vehicle data;
• weighing data;
• intervention history;
• maintenance.

The AMIU Bari specification goes in this direction: the required IT system had to manage deposits, weighings, the container fleet and the company vehicle fleet, for analysis and service optimisation purposes.

It is an important example because it shows that the value is not in the single electronic board, but in the relationship between different data.

---

How is data linked to collection management?

A possible operational architecture is:

In the case of an underground island, the IT system can also be linked to the container and the vehicle used for emptying.

This makes it possible to build an information chain in which the deposit event is not isolated.

---

What does integrating the system with the fleet mean?

Fleet integration can be designed at different levels.

In the simplest case, the system only knows when and where a station was emptied.

In a more complete architecture it can also receive information on collection, weighing and the vehicle used.

AMIU documentation relating to Bari’s smart islands expressly required an integrated system for monitoring the container fleet and the lorry fleet, in addition to deposit detection and weighing during collection.

For an operator this integration opens the possibility of correlating:

The result can be a much more detailed operational picture than a simple round calendar.

---

Pay-as-you-throw charging: where does access control end and measurement begin?

This is the point that requires the most attention.

The presence of a card or authentication system does not automatically mean that pay-as-you-throw charging is active.

Italian regulation distinguishes systems for point measurement of waste quantity from simple access systems.

The Ministerial Decree of 20 April 2017 sets out criteria for implementing systems for point measurement of the quantity of waste deposited in the public service and systems aimed at a tariff commensurate with the service provided.

ARERA, in its data collection activity on the sector, also distinguishes between solutions for point measurement of the quantity produced and the methods of user identification needed to attribute deposited quantities accurately.

Therefore:

access control ≠ point measurement ≠ pay-as-you-throw charging

They may be components of the same architecture, but they are not synonyms.

Why is this distinction important in a specification?

Because a requirement such as:

“Smart bin with RFID for pay-as-you-throw charging”

leaves too many questions open.

Instead one should specify:

• how the account is identified;
• which events are logged;
• which waste stream is measured;
• which magnitude is measured;
• by which method;
• which identifier is associated with the deposit;
• how data are validated;
• how they are transferred to the management system;
• which data must be retained;
• which systems must be integrated.

Only then does the requirement become verifiable.

---

User identification also raises personal data issues

When a credential is associated with a natural person or an identifiable account, the digital project must also consider processing of personal data.

The Italian Data Protection Authority has already addressed the relationship between separate collection, depositor identification and protection of personal data, recalling the principles of necessity and proportionality and distinguishing cases in which identification is actually necessary. The measure dates from 2005, so it must not be used as a substitute for the current legal framework, but remains a useful reference for understanding the problem.

In the design phase it is therefore advisable to define also:

• which data are collected;
• why they are collected;
• who may consult them;
• how long they are retained;
• how they are protected;
• which external systems receive the data;
• which information is actually necessary.

This aspect should be addressed together with software architecture design, not after hardware installation.

---

What should happen if the network fails?

This is a question that is often missing from technical specifications.

A smart system depends on power, electronics, communications and software. Defining operation when everything is online is not enough.

Degraded behaviour must also be defined.

For example:

• what happens if the data connection is temporarily unavailable;
• what happens if the credential cannot be verified online;
• what happens in the event of power loss;
• how the opening is managed during a fault;
• how an authorised operator can intervene;
• which data are stored locally;
• how they are synchronised afterwards;
• how loss or duplication of events is prevented.

The AMIU Bari tender included among the services technical assistance, operational support and maintenance of the hardware and software infrastructure, in addition to usage fees for the installed software systems.

This shows that the IT system should not be treated as an accessory separate from station management.

---

Power, communication and maintenance

Every digital function adds components to power, monitor and maintain.

Depending on the configuration, the following may be present:

• batteries;
• mains power;
• communication devices;
• antennas;
• readers;
• actuators;
• sensors;
• control units;
• opening systems;
• safety components.

The project should therefore define at least:

power + autonomy + communication + maintenance + component replacement.

It is not enough to request “remote monitoring” or “cloud connection”.

A contracting officer should be able to know what is installed, how it is powered, how it communicates and what happens at end of component life.

---

Which communication technology to use?

Communication technology depends on the site and project architecture.

The choice may involve, depending on the solution:

• mobile network;
• low-power networks;
• local gateways;
• wired links;
• local communication between sensor and control unit;
• other IoT technologies.

There is no universally correct technology.

The criterion should be the relationship between:

For a sensor that only needs to transmit a level value a few times a day, requirements can be very different from those of a station that must manage access, events, software updates and bidirectional communications.

---

Fill monitoring and round optimisation

Fill level is most useful when it can change operational behaviour.

A simple model can work as follows:

The model can be more sophisticated when deposit history, seasonality, calendar, waste stream type and fleet information are also used.

But an overly generic promise such as “reduces collection costs” should be avoided.

Economic benefit depends on how the operator uses the data, quality of detection, round planning and service conditions.

The sensor is therefore a decision-support tool, not the decision itself.

---

The smart island must also be designed for the user

Computerisation changes the deposit experience.

The user must immediately understand:

• which waste stream to deposit;
• how to identify themselves;
• where to present the credential;
• when the opening is unlocked;
• how much they may deposit;
• what happens when the deposit is finished;
• what to do if access is denied.

A technically advanced system can become problematic if the deposit cycle is hard to understand.

In the AMIU specification for Bari, for example, the deposit cycle is linked to user identification and, for non-recyclable waste, to closing the volumetric device before allowing a subsequent deposit.

This type of detail is significant because it shows that user interface design must be considered together with IT logic.

---

Operator staff must also be provided for in the system

A smart project does not end with the user.

Operators must be able to:

• identify the container;
• carry out emptying;
• check equipment status;
• intervene in case of anomaly;
• temporarily disable an opening when necessary;
• carry out maintenance operations;
• use the provided lifting system;
• consult the necessary information.

AMIU documentation requires, for example, training of staff responsible for bin maintenance on use of the lifting system.

This principle applies more generally: every automated function must have an associated operational procedure.

---

What should a technical requirement for a computerised island contain?

A specification or request for quotation should avoid vague descriptions such as “smart bin”.

It is preferable to define the system by function.

Identification

• type of credential;
• reading mode;
• account–device association;
• management of enabled accounts;
• procedures for lost or replaced credentials.

Access

• normally open or closed state;
• opening mode;
• authorisation times;
• handling of denied access;
• opening for authorised operators;
• emergency mode.

Deposit

• waste stream associated with the opening;
• any dimensional limitation;
• any volumetric control;
• number of loggable deposits;
• handling of subsequent deposits.

Measurement

• what is measured;
• unit of measure;
• required accuracy, where relevant;
• association with the individual account;
• data validation mode.

Fill level

• sensor technology;
• detection frequency;
• thresholds;
• alarms;
• historical data management.

Communication

• technology used;
• required coverage;
• transmission frequency;
• handling of loss of connectivity;
• communication security.

Software

• dashboard;
• authorised users;
• event history;
• reports;
• data export;
• APIs or integrations;
• alarm management;
• maintenance management.

Operational continuity

• autonomy;
• offline behaviour;
• fault handling;
• technical access;
• component replacement;
• assistance.

This structure allows different offers to be compared without relying on the generic commercial label “smart”.

---

What is the difference between a smart system and simple access control?

The comparison can be summarised as follows:

System	Identification	Controlled access	Deposit data	Fill level	Quantity measurement
Traditional container	No	No	No	No	No
Container with controlled access	Yes	Yes	Possible	Not necessarily	Not necessarily
System with fill sensor	Not necessarily	Not necessarily	Not necessarily	Yes	No
Full computerised system	Yes	Yes	Yes	Possible	Possible
System prepared for pay-as-you-throw	Yes	Generally necessary according to model	Yes	Optional	Yes, according to the measurement system provided for

The last row does not mean that any system with RFID can automatically be used to apply pay-as-you-throw charging. Measurement must be designed and validated according to the applicable framework.

The Decree of 20 April 2017 governs point measurement systems, while ARERA continues to collect information on measurement methods and user identification in the context of evolution of waste service charge regulation.

---

When does it make sense to computerise an eco-island?

Technology has greater value when there is a precise operational need.

Access control

It can be useful when the municipality or operator must limit use of the station to a defined set of accounts.

Fill monitoring

It can be useful when the operator wants to move from scheduling based solely on the calendar to management supported by actual container levels.

Deposit measurement

It can be evaluated when the service model requires quantitative measurement of deposits.

Pay-as-you-throw charging

It requires a further level of design, in which identification and measurement must be consistent with the tariff model and applicable rules.

Fleet monitoring

It can make sense in systems where container, vehicle and collection operation data are processed together.

AMIU Bari documentation is a concrete example of the latter approach, because it links deposits, weighings, containers and fleet within an integrated IT system.

---

When does technology add complexity without solving a problem?

Not all stations need the same level of computerisation.

A digital system can become disproportionate when:

• access control is not needed;
• the operator will not use the data;
• there is no central system to receive events;
• maintenance is not provided for;
• procedures in case of fault are not defined;
• the operating cost of the technology is not justified by the expected benefit;
• “smartness” is requested as a commercial feature but without a measurable objective.

The right question is not:

“Can we add a sensor?”

but:

“Which operational decision do we want to take thanks to that data?”

If the answer is not clear, the requirement probably needs to be reconsidered.

---

The true architecture of a computerised eco-island

For a municipality or operator it is useful to reason about the system in six levels.

Level 1. Physical point

Container, opening, tower, platform, underground or semi-underground structure.

Level 2. Interaction

Reader, credential, button, foot pedal, handle, display or other deposit device.

Level 3. Sensors

Fill level, status, opening, any quantitative measure and other necessary signals.

Level 4. Connectivity

System through which data are transferred to the platform.

Level 5. Software

Database, dashboard, alarms, history, reports, user and asset management.

Level 6. Operational process

Collection, maintenance, assistance, control and use of data for decisions.

If one of these levels is missing, the infrastructure can still work, but with a different degree of computerisation.

---

The project should also define who owns and manages the data

For a public supply or a long-term service this topic is particularly important.

Before commissioning, it is advisable to define:

• who is the data controller;
• who manages the platform;
• who can access the dashboard;
• who can modify accounts;
• who manages identifiers;
• how data are exported;
• which format is available;
• how integrations are managed;
• what happens to data if the service ends;
• who maintains hardware and software.

A supply that leaves the municipality or operator dependent on a closed system without defining access and data export can create long-term operational lock-in.

This applies especially when the system is integrated with charging, management systems or other IT services.

---

Checklist for a smart eco-island

Before approving a computerised project, the municipality, contracting officer or operator should be able to answer at least these questions:

User

• Who may deposit?
• How are they identified?
• How are credentials managed?
• What happens if a card is lost or not working?

Container

• Which container is monitored?
• Does it have a unique identifier?
• Which events are logged?

Access

• Is the opening normally closed?
• How is opening authorised?
• Is there a mode for operators and maintainers?

Deposit

• Is access logged?
• Is opening logged?
• Is quantity measured?
• Is there a volumetric limit?

Fill level

• Is there a sensor?
• Which parameter does it return?
• Which thresholds generate an alarm?
• Who receives the alarm?

Communication

• How are data transferred?
• What happens when the network is unavailable?
• What is the system autonomy?

Software

• Which data does it show?
• Which reports does it produce?
• Are exports or APIs available?
• How are administrative users managed?

Service

• How does the data change collection scheduling?
• How is emptying recorded?
• How are maintenance and anomalies handled?

Regulation

• Must the system support point measurement?
• Which waste stream must be measured?
• Which tariff model is to be supported?
• Which regulatory requirements must be verified?

Personal data

• Which information is linked to the account?
• What is the purpose of processing?
• Which parties access the data?
• What retention periods and methods are provided for?

This checklist avoids the project being defined solely in terms of hardware.

Access control, sensors and charging: three different projects that can coexist

One reason “smart” systems are described too generically is that three different needs are often mixed together.

Access control
Serves to decide who may use the container.

Fill monitoring
Serves to know when the container needs attention.

Point measurement
Serves to quantify the deposit according to a defined method.

An island may have only one of these functions, two or all three.

Design should therefore start from the service objective and then choose the necessary hardware.

This is a particularly important distinction in view of pay-as-you-throw charging: the regulatory framework treats measurement of waste quantity as a specific requirement and not as a simple consequence of user identification.

The value of the smart island lies in data that become usable

The most visible part of the island may be a simple tower with a deposit opening.

The most important part for the operator may be what is not seen: the data structure linking users, containers, deposits, fill levels and collection operations.

Bunder states for its container range the possibility of integrating access control and fill level, while the technical documentation of a recent AMIU public supply shows how these functions can be placed in a broader platform including deposits, weighings, containers and fleet.

For this reason, in designing a computerised island, the final question should not be “how much technology can we install?”, but:

which information does the operator need to manage that collection point better and which components are really necessary to produce it?

This approach allows technology to be evaluated in terms of the service, keeping access control, operational monitoring and deposit measurement separate.