Patent Application
20080040182
In the following advantageous implementations of the invention will be further described by means of examples and by means of the figures:
a and
The embodiment according to
It is advantageous to perform a gathering of environmental data, especially of environmental performance data and—resulting—environmental impact data for different carriers.
The described example contains the names of several existing and operating transportation and logistic companies like DHL Express and DHL Danzas Air and Ocean. Examples of information technology production systems are: Rasti, NPS, +2000, Exact, LOGIS R and LOGIS C.
These names are only used to show, that the invention can be carried out with different carriers. The names of the carriers do not limit the scope of the invention. It is possible to carry out the invention in any transportation system, respectively any information technology production system.
The gathered data are transferred to module 104 for updating and/or calculating the environmental data.
A calculation is performed with regard to respective parameters.
The updated and/or calculated data are transferred to a storing module 106.
The storing module can be implemented in different configurations.
The depicted Implementation shows a preparation of an emission report 110 according to the stored data.
This implementation is especially advantageous to inform users of the transport system about the environmental impact of transport.
However it is also possible to use the stored data for one or more of the described routing and/or transportation processes.
Therefore, it is especially advantageous to implement at least a part of the stored environmental data in a logical node or a computer connected to a physical router.
It is even more preferred to use the stored data for the routing and/or transport as well as for the retrieving and/or report as it is described in the right part of
The data retrieving and/or report allow reports for each transport process as well as periodic reports 112. The reports can be analyzed according to one or more of the following categories: Client, customer id, transportation (e.g. km, ton, tonkm), country, period of time, different emissions, energy use or shipment.
Especially advantageous is a flexible report out take with parameters chosen individually. Examples could be for specific relations, listing of euro classes of transportation means.
Within preferred embodiments the environmental data are incorporated into the routing mechanisms in order to make the corresponding routing decisions. Furthermore, a mechanism is advantageous to be able to track the packages.
A transport system like a mail delivery system can use the environmental data to internally sort and distribute letters and packages to the correct truck for delivery. The size, due date etc. of each letter and package are determined.
Furthermore, an appropriate truck is identified by comparison between ecological requirements of the transport and environmental performance data of the truck.
Alternatively another preferred embodiment of the invention includes flexible mechanisms meaning that we promise to some where in the transport system to transport the agreed transport volume. This might change if alternative fuels and trucks are capable of using them are easily available.
Information about the environmental requirement data is used to accompany the letter and package and to deliver the package to the correct destination. It is also possible to add environmental requirement data to each letter and package. However, in this case scanners are needed.
Externally the same mechanisms may apply. Whereas the letters and the packages are distributed via other networks, the environmental requirement data may accompany the letters and packages via any appropriate communication network as for example the Internet. This environmental requirement data is then used to make routing decisions.
A further implementation of the invention relates to a computer integrated manufacturing company. In a computer integrated manufacturing company the routing of construction parts and tools may be done with regard to environmental requirement data and/or environmental performance data.
Once the size, the due date/time, the environmental impact data and the destination are determined, a communication packet that takes care of the routing accompanies the construction parts and tools.
Weighted fair queuing may be used to speed up and delay at least one leg of transport process.
Through flow control mechanisms it is possible to adapt parameters, especially transport capacities of the transportation system to the need of the users.
If the goods can be separated, segmentation and from time to time a reassembly may be executed. The segmentation is for example performed at the sending station or at one or more of the mechanical routers.
The different packages which are transported have different sizes, masses and should meet different needs. The different needs are most preferably reflected in special Quality Of Services (QOS) mechanisms. QOS specifications are for example environmental performance data of the transport means, and/or a fast or a secure delivery. Most preferably the QOS specifications are categorised, for example according to special categories, which represent for example goods which have to be handled according to specific environmental requirement data.
The environmental requirement data are an example of especially advantageous quality of service specifications.
However it is possible that further aspects are used for the quality of service, for example a desired speed of transport.
Though the invention can be carried out without usage of protocols some implementations of the invention can be further improved by implementing protocol mechanisms.
The protocol mechanisms can be used to do traffic management. For example in case of congestion, a routing protocol could determine, especially in real-time, a different route and router the car by sending signals to the receiver in the car. An interface from the router to a traffic control system is used.
In the following the invention will be described by different concepts with different connections between actual machines and routing network.
The environmental data according to the invention especially the environmental impact data, the environmental requirement data and the environmental performance data can be implemented in various ways into the transportation procedure.
As described it is especially advantageous to implement environmental data into the routing of the objects. However it is as well possible to use the environmental data for planning the transport process and/or for calculating the environmental impact of a certain transport.
It is especially advantageous to include environmental data into the route planning tools is especially advantageous for a comparison between different modes of transports or linked to geographical restrictions/concerns e.g. in especially polluted areas.
For example it is possible to perform routing processes to guaranty that a certain environmental quality is maintained.
For example it is possible to perform the routing in a way that the transport processes fulfill certain criteria.
Such criteria can be derived from customer based directives and/or directives implemented by law and/or official actions.
For example the routing processes are fulfilled in a way that the following directives of the European Union are fulfilled:
If the route planning concerns one mode only e.g. truck transports, its' objective goes hand in hand with environmental concern. Higher efficiency means lower environmental impact per shipment.
It is possible to use more centralized implementations of the inventions.
More centralized versions of the invention include central planning and/or stearing of transport and/or calculation procedures.
However it is also advantageous to use decentralized implementations of the invention.
Such decentralized implementations of the invention can for example be carried out in the following way:
The invention especially covers the following embodiments:
Environmental requirement data accompany the physical objects. This is for example possible by adding digital information to the physical objects, for example by printing codes and/or writing information to transponders.
The physical routers are connected to a database which contains environmental performance data of transport means which are accessible by the routers.
Examples for different transport means for one router are different trucks that operate from a cargo center.
Examples for accompanying the physical packages with logical packets are labels or transponders attached to the physical objects.
The labels and/or the transponders may contain a various data suitable for logistic processes.
Examples for these data are identification information about the physical object, a delivery address, a sender address and charging relevant information as for example digital franking marks.
Especially advantageous implementations of the current invention propose to add to this data environmental data, for example environmental impact data and/or environmental requirement data.
Whenever a physical object is received in a router, the router informs the machine on what to do and waits for a confirmation that the actions have been executed.
The embodiments described above can be combined with each other or with any of the embodiments described before.
The described examples of transportation systems that are designed and/or operated according to the invention show that the invention can easily be adapted to other transportation systems. Therefore the invention is not limited to a special transportation system.
The invention furthermore relates to methods for processing postal deliveries as letters, parcels and packets, transport pallets or transport containers.
A preferred embodiment of the invention involves a detection of information present on at least one surface of the physical object in such a way that, on the basis of the information present on the surface of the physical object, environmental data, for example environmental requirement data is used for the routing and/or for analysis and/or representation and/or for a compensation by transporting a corresponding volume in a “green way” that means with less impact on the environment.
An example of the implementation of the environmental data is a direct printing on the physical object. However, it is also possible to first print a medium, for example, a label, and to subsequently apply it onto the physical object.
This is advantageous to increase customer satisfaction and realization of the green shipment. It is possible but not necessary to use the environmental data for any sort of sorting or routing purposes.
The neutralization of the emission will in one advantageous implementation be done through compensation rather than reduction at the source. This is especially useful for air shipments where at the moment no alternative fuels are available.
The term “environmental data” is by no means to be understood in a limiting fashion and especially comprises all depictions of data in an optically recognizable and/or machine-readable form that can be used for sorting, transporting or delivering the physical object.
An especially advantageous embodiment of the method is characterized in that the physical objects are processed within the scope of a two-stage process, whereby the physical objects are already completely coded in the source region and undergo preliminary sorting according to target regions in a first sorting step.
In an advantageous embodiment the physical objects undergo fine sorting into smaller units in another sorting procedure.
Moreover, it is advantageous for the environmental data, for example the environmental requirement data, to be applied onto the physical object as a barcode.
In any case it is simultaneously appropriate to include the environmental data, for example the environmental requirement data in a transponder which is attached to the physical objects or a transport unit containing the physical objects.
The coding, or the labelling, is preceded by determination of the environmental requirements in which the environmental impact data are found on the basis of the recognizable environmental performance data by means of linked files from the data, including a conversion file.
The invention also comprises a device for processing physical objects.
Additional advantages, special features and practical refinements of the invention ensue from the sub claims and from the following presentation of preferred embodiments of the invention making reference to the drawings.
Afterwards an especially advantageous implementation of the invention is described as an ACCEPT-Implementation.
The preferred ACCEPT-Implementation includes an Automatic Customer Calculation of Environmental Performance Tool.
The idea of ACCEPT is to produce Emission reports for customers and operators. Those reports will describe the amount of Emissions a specific customer's shipment has produced for a specific period.
In order to facilitate the explanation of the ACCEPT-Implementation of the invention the following definitions are used:
Definitions
The ACCEPT system is for example useful to calculate emissions for shipments. The calculation is performed, in brief by multiplying the distance, weight and the emission values for a specific engine model. One instance of ACCEPT is meant to serve one country's all shipments, domestic, international, air and so on.
The system calculates the distance for a shipment in different ways:
The method to use is chosen by the ProductID term in the Shipment.
The fuel consumption, max load weight and fill factor for a vehicle and operator is imported from an external system, which is for example called T-Web, or set to a default value defined by ACCEPT. The fuel consumption for a specific shipment can be set in one of three values.
This section describes the different ways to calculate emissions for shipments.
Factor=VolumeWeight/(MaxLoadWeight*FillFactor)
TransportEmission=FuelConsumption*LegDistance*EmissionValue*Factor
ShipmentEmission=TransportEmission+n1
Factor=VolumeWeight/(MaxLoadWeight*FillFactor)
TransportEmission=FuelConsumption*City-to-city-distance*EmissionValue*Factor
ShipmentEmission=TransportEmission
This embodiment relates in general to the field of transport routing system. More particularly, this aspect of the invention relates to an extensible model system architecture for integrated material and environmental data planning, and integrated transport and distribution planning.
Manufacturers and distributors commit to time critical transport and delivery of goods as a regular part of their operation. Often, the transport and distribution transport is complex, having many different material and environmental data constraints that simultaneously affect the implementation of the transport.
Due to the complexity of the transports, many different software tools have been developed to implement environmental data.
This preferred aspect of the invention provides an extensible model architecture for a transport routing system that allows an implementation of environmental data in the transport process.
More particularly, in one embodiment, the present invention provides a computer central control computer for modeling a transport capability on a computer. The central control computer is programmed with software and comprises an operation model type for defining a plurality of operation models. Each operation model represents activities that relate to the transport of the physical objects.
A resource model type is used for defining a plurality of resource models. Each resource model represents environmental data available for use in performing an activity and rules for allocating environmental data to the activity. An environmental data type is for defining a plurality of environmental data sets. Each environmental data represents rules for controlling a transport route of material between locations.
The operation model type, environmental data type, and resource model type each comprise a plurality of fields defining attributes. The plurality of fields includes a plurality of extension selector fields that each allows a user to specify one of a plurality of extensions that augment a model with additional fields and semantics. The model type specifies a base set of fields and semantics which includes fields that select extensions that specify additional fields and semantics that can be added to a particular model.
These measures allow handling different environmental data.
Examples for the environmental data are environmental requirement data, environmental performance data and environmental impact data.
The term environmental data is used for each of these types of data.
The environmental requirement data are data concerning and/or implementing desired or required economic standards.
The environmental requirement data are for example: Requirements concerning a desired level of emissions and/or another influence on the environment.
These data can be related to different aspects of transport.
For example it is possible to define that a single transport has to be emission neutral or that all transports of a customer together has to be emission neutral, or that a certain level of air or water quality is maintained in a place, a city, a region, a country or in total.
Environmental performance data describe the ability of a means to perform a task in relation to an environmental impact. An example for this is the capability of a truck to transport a certain amount of physical objects with specific parameters—especially weight and size—with a certain emission. For example the relation between ton, kilometers and carbon dioxide emissions. The invention further includes means with a positive effect of the environment, especially devices for reducing the content of hazards components in the air.
The invention proposes a complex database with knowledge information about interdependencies between different parameters and therefore allows to minimize an effect to the environment.
The invention allows to handle this with a multiparameter approach with detailed information about the ecological efficiency of transport means and parameters to influence this ecological influence, for example by using biofuel.
The presence of a field in a model is preferably dependent upon a value of another field in the model. Defined operation models, environmental data, and resource models are stored as nodes in an interrelated transport network model. The transport network model is formed by a plurality of operation models each specifying environmental data from which material is transported and environmental data to which a physical object is transported and specifying resource models having environmental data used in performing the activity specified by the operation model. In this manner, both transport and environmental data usage are simultaneously represented along with timing constraints between activities. According to the present invention, to model a plan for a transport, a plan network model is constructed upon the transport network model. An operation-plan model type is used to define a plurality of operation-plan models. Each operation-plan model represents a plan for performing an activity represented by an operation model. A resource-plan model type is used to define a plurality of resource-plan models. Each resource-plan model represents a planned usage of environmental data represented by a resource model.
In one preferred embodiment an operation-plan model type is used to define a plurality of operation-plan models. Each operation-plan model represents a planned transport route of a physical object represented by an environmental data element. A plan network model is formed by a plurality of operation-plan models each specifying resource-plan models planned to be used in performing the activity specified by the operation-plan. The nodes of the plan network model are built upon and refer to the nodes of the transport network model. According to the present invention, the transport network model represents possibilities of what can be done, and the plan network model represents that which is planned to be done. According to one aspect of the present invention, each model type has one or more extension points that may be used to extend the basic model type in order to support the information needed to create the user defined models. For each extension point, a user may select an appropriate extension to model a particular aspect of the user's system. According to another aspect of the present invention, several elements of a user's transport model may share data in a hierarchical fashion referred to as families.
One model inherits all of the data of the parent model unless it is specifically overridden by a designation in the model. A central control computer implementing the teachings of the present invention may provide for date affectivity of models using the families feature. It is a technical advantage of the present invention to use extensions to define the elements of the transport or system being modeled because it reduces the amount of data that needs to be stored in a memory device without reducing modeling power. According to the teachings of the present invention, data for each element of the modeled transport is stored at a node of a user model or transport network model. The data stored at a node comprises only the data for the fields corresponding to the extensions that are selected by the user. The system does not store a zero quantity for each 60 field not chosen by the user. Therefore, the use of extensions reduces the size requirement for a memory device in a system implementing the present invention. The central control computer of the present invention can be, but not necessarily, implemented using object oriented programming. Use of object oriented programming supports simultaneous use of multiple types of models for the different elements of the planning problem.
In one embodiment, the present invention provides a software based computer system for modeling various transports. For example, the computer system may model a transport means used to transport a particular physical object or product. The central control computer may also be used to model a product distribution channel, a supply chain, or an order fulfillment transport.
In a preferred embodiment a transport is modeled using three primary model types: an operation model type, an environmental data element type, and a resource model type. A plan for that transport is similarly modeled with three associated primary model types: the operation-plan, environmental data-plan, and resource-plan. A user uses a model type as a template to create a model. For example, an environmental data element type is used to create a model of environmental data. Each of these user defined models is stored as a node in a transport network model of a user's transport. The model types used by the system are extensible in that each model type may have one or more extension points that allow a user to customize the model to represent the user's transport. For each extension point, a user may choose from numerous extensions the one that is best suited to define a particular aspect of the user's system or transport. Each model type has a list of predefined extensions from which the user may choose. Each extension defines fields that extend the data and meaning associated with a model type. These extensions and fields define the way in which the model types interact. Each user defined model is defined by a model type, one extension for each extension point of the model type, and data for each field of the model type and extensions. Possible features of each of the model types are discussed in detail below.
The Operation Model Type may be used to create operation models which represent activities that can be performed. As used herein, “operation model type” means a general model for activities that may be modeled by the software. “Operation mode” and “operation model” are used interchangeably to represent a specific operation defined by a user using the operation model type. This convention is also used with respect to resources. An operation model type models a transport, activity, or action that transforms or moves physical objects resulting in a transport route.
Operations may require resources with specific skills. Those resources model may include transportation and/or storage.
An operation can use any number of resources, with different run times, and with staggered start and end dates. Thus, a single activity or a whole series of activities can be modeled with a single operation. This is important for having sufficient flexibility to model diverse activities. A preferred embodiment of the invention allows a routing to be modeled as simply a particular kind of operation that consists of other operations that are run in sequence. The relationships between those sub-operations can be different depending upon the chosen extension.
So, an operation can model a simple routing (a sequence of operations allowed to spread), a transport route routing (a sequence of operations which must transport route into one another), a set of operations that can be run at the same time, alternates (a set of alternate operations), and other combinations. Further, since routings are modeled as operations, they can be put in other operations.
For example, a simple routing operation may consist of different operations, called legs.
An operation can also model simply the environmental impact data for transporting a physical object (operations that just model the transform of physical objects, but do not model the environmental data required to do that).
Similarly, an operation can model simply the environmental impact data for transporting a physical object.
Other operations can then combine the environmental impact data with operations that properly consume environmental data.
For example, some transport software defines operations such that resources can be loaded just during portions of transport time. For ease of interfacing such packages or databases, transport extensions can be provided with the identical specification. That transport generates a routing-like operation containing auto-generated sub-operations that contain the different phased resource loadings.
An advantage of the operations model type design is simplicity and consistency. By providing a simple building block that is extensible and can be flexibly combined with others, a great deal of modeling capability is provided without complicating the common simple cases. In this way, the critical operations and resources can be modeled in adequate detail and time.
A user may select an extension from the operation model type to, for example, define a transportation model.
This model may contain a predetermined, constant time for loading material, followed by a run time which is a factor that is multiplied by the quantity of material that is being transported, followed by an unload run time which is constant. The load, run, and unload phases may each require use of different resources.
Operation models represent activities that consume supplies, transport physical objects, and/or utilize environmental data. Such operation models define the activities and precedence (timing) constraints in a transport. In transport, a sequence of operations is referred to as a routing. A routing is represented as an Operation model with a routing extension which defines the behavior of that operation to be a sequence of other operations. Similarly, the specification of alternate resources, alternate operations, and alternate routings can be done with an operation model and an extension which defines the behavior of that operation.
A resource model type may be used to create resource models which represent aspects of a transport that have predetermined environmental data. For example, a resource model may represent resources in a transport process. A resource model may represent a transport means such as an airplane, a ship or a truck, thus implementing the environmental impact data of a transport that has a predetermined environmental data limitation (such as carbon emission).
The resource model type may provide various extensions from which a user may choose to define an actual environmental data constraint on its transport. For example, a simple extension may only have a single field setting a maximum environmental data constraint. Such a resource model may, for example, represent a truck which has defined environmental impact data.
The environmental data type is used to create environmental data which manage physical objects transported in the modeled system. In other words, an environmental data element represents the management of a particular physical object.
Additionally, the environmental data type may have an extension that defines ordering policies.
A transport network model is a set of user defined models which may be stored in a computer memory. The stored nodes define, for example, the user's transport which is to be used to manage a particular. A user defines a level of desired environmental impact data by selecting model types and the appropriate extensions of these model types, as described above, to form models of the elements of the users' transport.
The nodes in transport network model may be connected together in many different ways to achieve different results. Transport network model represents all of the possible interconnections between starting place and destination of the transport of the physical objects.
A preferred transport network model represents the possible routes that material may be transported according to a route in a transport to be modeled. The central control computer of the present invention uses the information in a transport network model to create plans for implementing a particular material transport route path to model a transport. The interconnected nodes of the transport network model used to represent a particular plan may be referred to a as a plan network model or plan.
The central control computer according to the present invention may create a plan network model as a result of several different events. In general, a plan network model provides definitions as to quantities and timing for elements of the model. For example, the inventory level for a physical object managed by a particular environmental data may drop below an allowable level.
The central control computer may create a plan network model for replenishing the inventory of that environmental data. Alternatively, a plan may be created using the transport network model in response to customer orders. The central control computer of the present invention may create a plan network model as follows. For each activity in a user's transport, the central control computer creates an operation plan model from an operation-plan model type using extensions from the corresponding operation model. The system provides the operation plan model with the start and end dates, alternate selections, and other information needed to form a plan for a particular execution of that operation.
For each resource model that is used by an operation plan, the central control computer creates a resource plan model from a resource-plan model type and the extensions corresponding to the resource model. The system provides the resource plan model with all of the environmental data reservations placed on it by the operation plan models. For each environmental data according to which physical objects are transported or to which physical objects are transported by an operation plan, the central control computer creates an environmental data plan model from an environmental data-plan model type and the extensions of a corresponding environmental data. The system provides a plan model with inventory levels, ordering policies and any other information needed to plan the management of the transport route of physical objects in the transport.
Preferably the central control computer functions as system for modeling a transport capability for use in a transport routing system, the central control computer comprising: a plurality of operation models defined from an operation model type and stored by the computer system, each operation model representing an activity that can be performed by a transport; a plurality of environmental data defined from an environmental data element type and stored by the computer system, each environmental data element representing rules for controlling a transport route of material between activities, the activities represented operation models; the operation model type and environmental data type each having a plurality of fields defining attributes.
In an advantageous implementation the central control computer operates with a transport network model, stored by the computer and interrelating the operation models.
The transport network model can be formed by the plurality of operation models, each specifying environmental data according to which material is transported.
A material usage is preferably represented by the transport network model along with timing constraints between activities.
In a preferred embodiment the transportation system, especially the central control computer steering the system, further comprises: a plurality of resource models defined from a resource model type and stored by the central control computer, each resource model representing environmental data available for use in performing an activity and rules for allocating capacity to the activity, the activity represented by an operation model; the resource model type having a plurality of fields defining attributes; the transport network model further interrelating the resource models as logical nodes.
The transport network model may further be formed by a plurality of operation models each specifying resource models having environmental data used in performing the activity specified by the operation model; such that both material and environmental data usage are simultaneously represented by the transport network model, preferably but not necessary along with timing constraints between activities.
The central control computer is for example a computer with a database for storing environmental data and with interconnections to sensors and/or other computers capable of handling sensor data. Preferably the central control computer is coupled with means for implementing environmental data.
It is for example possible to connect the central control computer to at least one other computer which allows user to define values for environmental data.
It is advantageous to sign different user rights to different users and/or different types of users.
For example a customer is capable of define requested environmental data.
This allows for example a user to choose his own level of desired ecological quality of his transport, for example choosing zero-emission transport.
It is furthermore advantageous to assign other rights to other types of users.
It is for example possible to allow operators of the systems to implement a handling with regard to environmental data. This handling is for example bases upon ecological standards defined by competent authorities.
It is furthermore advantageous to implement an environmental data type wherein the environmental data type has an operation that defines how data managed by an environmental data element is stored. It is furthermore advantageous that the environmental data type has an operation that defines how material is received into an environmental data element.
It is further preferred that the central control computer comprises a plurality of resource models defined from a resource model type and stored by the computer system, wherein each resource model represents environmental data available for use in performing an activity and rules for allocating capacity to the activity, the activity represented by an operation model; wherein the environmental data type includes an operation that defines how material managed by an environmental data element is stored.
The specified operation model contains information about the operation that defines how physical objects are transported or supplies are handled.
Each operation model may specify another operation and each environmental data element may specify an environmental impact factor.
The usage of environmental data that may specify a range of dates during which the model is effective.
A preferred embodiment further comprises a computer for modeling transport capability.
Advantageously the central control computer comprises:
It is further advantageous to utilize a plurality of resource models defined from a resource model type, each resource model representing environmental data available for use in performing an activity and rules for allocating environmental data to the activity; the resource model type having a plurality of fields defining attributes; the transport network model further formed by the plurality of operation models each specifying resource models having environmental data used in performing the activity specified by the operation model; such that both material and environmental data usage are simultaneously represented by the transport network model along with timing constraints between activities.
A preferred embodiment of a method for modeling a transport further comprises an evaluation of capability for use in transport routing system on the computer system, the method comprising: defining a plurality of operation models from an operation model type, each operation model representing an activity that can be performed by a transport; defining a plurality of environmental data from an environmental data element type, each environmental data representing rules for controlling a transport route of material between activities, the activities represented operation models; and interrelating the operation models and the environmental data as nodes in a transport network model; the transport network model formed by the plurality of operation models each specifying environmental data from which material is transported and environmental data to which material is transported; such that material usage is represented by the transport routing system on the computer system.
The preferred embodiment of the method further comprises a plurality of operation models each specifying environmental data from which material is transported and environmental data to which material is transported; such that material usage is represented by the transport network model along with timing constraints between activities.
This preferred embodiment further comprises: defining a plurality of resource models from a resource model type, each resource model representing environmental data available for use in performing an activity and rules for allocating supplies to carry out transport processes.
Advantageously, the activity is represented by an operation model which interrelates the resource models as logical nodes in the transport network model.
The transport network model may further formed by the plurality of operation models each specifying resource models having environmental data used in performing the activity specified by the operation model; such that both material and environmental data usage are simultaneously represented by the transport network model along.
A functional view 200 of implementations according to the ACCEPT system is depicted in
Advantageous databases for carrying out the invention are depicted in
The table Parameters in ACCEPT contains run parameters for ACCEPT. The parameter Period is used to set the month for which a report will be created by the stored procedures.
Representation of how the data is imported from the production systems, calculated and moved to the reporting database by the use of stored procedures; is described afterwards in more detail.
The following table describes the execution order to create different reports.
Stored Procedures for Loading of Code Tables
Preferred steps to add a new Source system to ACCEPT are described below:
A first preferred embodiment of the ACCEPT-system handles data for one country e.g. Sweden. To add a new country it is useful adding a completely new instance of ACCEPT database and DM ACCEPT database it is useful to add. ACCEPT database for Sweden growth approximately 2 gigabyte per month excluding distances, emissions, operators and vehicles.
Afterwards calculation methods for a transport emission report according to the invention are described in detail:
The described calculation methods and general data allow different ways of calculating environmental performance of cargo forwarded.
The ACCEPT system calculates the environmental performance of each cargo shipment handled by a transport carrier, which is afterwards without limitation named DHL. A calculation is performed for each relocation carried out during the transport of a shipment through the DHL transport system. The result from each relocation is then summarised in order to answer different questions, e.g.
Cargo data is obtained from the information systems of DHL. The data for the transported weight is used as the base for the calculations. This means that the environmental performance of each relocation is related to the weight of the investigated shipment/goods.
The weight is given as the volumetric, or dimensional, weight. This means that the physical weight of the shipment is used if the density of the shipment exceeds 250 kg/m3. Otherwise the volumetric weight is calculated as the volume of the shipment multiplied by the factor 250 kg/m3.
The following parameters are evaluated:
The base for the calculation is continuously updated why the values are only valid for the ‘present’ system at any given time.
The emissions reported are emitted within the following geographic boundaries
The calculation only covers emissions directly connected to the operation of the vehicle, train, vessel or aircraft. This includes engine exhaust emissions (road, rail non-electric, sea and air) and emissions from power plants engaged in the generation of consumed electricity (rail electric).
Emissions related to the following activities are implemented in more complex implementations of the invention:
The emission report is based on vehicle data supplied either from the vehicle operator or by application of standard default values relevant for the network of the transport carrier. The same calculation method is applied regardless of the data source. The following vehicle data is used in the calculation:
The ACCEPT-systems calculates the environmental performance of each relocation. The system uses the most specific information available. The following priority is used:
The emissions from the lorry are split between the cargos carried by the vehicle. The actual amount of cargo carried by each specific vehicle is usually not known. Instead, the following optional hierarchy is applied:
The average values calculated in 1-3 are based on data for one calendar year.
Emission levels: Fuel-, Engine- and Exhaust cleaning combinations
The calculation is based on the emission level stated for different combinations of fuel and engine type (i.e. Euro classification).
The fuel-specific emission was found to vary somewhat with road type and vehicle type.
Emission data for light duty vehicles is only presented for the urban traffic since these vehicles are mostly used for distribution in urban areas.
The applied diesel engine emission levels are adopted from the material presented by a competent source.
The following emission control devices are applied with stated reduction of emissions.
Cargo capacity is defined as the physical weight carrying capacity of respective vehicle. The calculation of the cargo capacity utilisation uses data for the volumetric weight of the investigated cargo shipment. The capacity utilisation is defined as the loaded volumetric weight divided by the maximum allowed carrying capacity.
The environmental performance data for the vehicle is divided among the cargo shipments in proportion to their volumetric weight, using the following formula:
The transports between the terminals are handled in the same way as the full truckload.
The environmental performance of the transport between the terminal and the customer (both pick up and delivery) is calculated as follows:
Some integration terminals are selected in order to represent different daily flow volumes, geographic coverage of operations, types of distribution vehicles etc. The total environmental performance for all delivery and pick-up traffic to and from each terminal is calculated. This amount is divided by the total amount of cargo handled in the terminal over the same period. The result is an average environmental performance per tonne cargo passing through the terminal. The rest of the terminals are categorised according to one of the investigated terminal types.
When information about the distance between the terminal and the origin/delivery address of a specific shipment is available the system will recognize it and use the specific characteristics of each truck. The environmental performance for the pick-up/distribution of a shipment is only depending upon the (volumetric) weight of the shipment.
‘Green tonne’-trucks are only considered for the calculation of the environmental performance for the goods sent by customers buying this service. The environmental performance of these trucks, and the load carried by them, is therefore excluded in the calculation of the terminal average value.
The ACCEPT system handles transports with cargo train in one ore more countries, as for example Sweden. In one advantageous implementation, only trains pulled by electrical engines are considered.
Data for rail transport is given for the transport of the following cargo units:
The emission calculations for trains are based on the weight of the cargo. The following default values are used for these units:
The cargo types are transported on different wagon types, for example the following Swedish wagon types:
The emissions reported for the electrical train are those emitted from the power plants balancing the electricity use. The electricity need for pulling a typical cargo train is combined with the emission profile for the selected mix of power plants, this in order to find the emissions related to the transport. These emissions are then divided between the transported cargos in proportion to the net physical weight.
The electricity demand for pulling a typical cargo train is calculated by using the method suggested by the EcoTransIT project (also adopted by NTM), see EcoTransIT 2003. The calculation is made for a block train of 1000 tonnes gross. This weight is entered into the formula presented in Table 9 below.
The electricity demand is thus found to be 0.021 [kWhel/ton-br×km], as measured at the engine.
There are losses in the transmission of the electricity from the power plant to the engine. The losses are moderate for the high voltage transmission to the connection to the rail network. The losses between the outtake from the grid to the engine are higher, due to frequency modulation and lower transmission voltage in the catenaries. The following values used by NTM are applied in the calculation:
Next step in the calculation is to find the gross weight of the wagons carrying the 3 different loaded cargo units. The following Tara weights and cargo capacity data are used in the calculations:
Tonne is a mass unit. It equals 1000 kg.
The wagon gross weight is connected to the carried unit(s). These data are then connected to the calculated emission per gross ton in order to find the environmental data connected to the transport of one unit 1 kilometre.
A mix of the electricity production in the Nordic countries (Norway, Denmark, Sweden and Finland) was used in the calculation. The production volumes from each country were combined with the emission data for Swedish electricity generation. The following mix was applied:
This kind of values (also e.g. table 14) is an example and will vary with time and between countries and need to be updated
The emission profile for this production mix as presented below was applied in the calculations.
The following calculation result is used in the ACCEPT application.
The following cargo types are applied in the calculation for sea transport: 20 feet container, 40 feet container, semi-trailer, articulated truck, rigid truck and trailer.
The ACCEPT systems calculates the environmental performance of cargo transported by ships by applying data for a number of representative vessels. The selected vessel types are presented in Table 13 below. Environmental data for two container sizes and 3 different road vehicles are calculated, see Table 13 for the selected combinations of cargo and vessel type.
The emissions for the selected ships are calculated in the following steps:
The allocation procedure in step 4 differs between the vessel types, see below.
The calculation is illustrated by the example of an older and slow RoRo vessel (Older Danish vessel, DANA CIMBRIA).
The fuel consumption is not stated in the vessel information. The consumption is calculated by assuming a specific fuel consumption of 200 g/kWh and a 85% power outtake at cruise speed, i.e. 17.5 knots. With an installed engine power of 6600 kW is the fuel consumption given as:
FC=0.85×6600×0.200=1122 [kg/h]
with a speed of 17.5 knots=32.4 km/h,
The emission profiles are selected based on the combination of fuel type and engine speed. From known data-bases the following emission data are extracted for the use in the calculations for the ACCEPT system:
The RoRo vessel is typically powered by a medium speed diesel engine (MSD) burning residual oil. The emission per km is calculated by multiplying the fuel consumption by the emissions stated in Table 14, yielding the results presented below:
The total cargo capacity of the selected RoRo vessel was stated as 2 000 lane meters. The utilisation of the vessel is difficult to assess since this type of information (often) is considered as business sensitive information. A frequently stated CCU (lm) of 90% is used in these calculations. This value could be a bit on a high end and should probably be changed to 75-80% in a future up-date. The share of the ship emission to allocate to one lane metre is then calculated as 0.056%, see below.
The following proportions then calculate the emission to each cargo unit:
The emission per cargo unit is then found by the combination of the ship emission and the share stated above. The result is presented in Table 17.
The following vessels are used in the calculations for transports with RoRo ships:
A RoPax vessel is carrying both passengers and vehicles. The RoPax ships usually offer substantial volumes for passenger purposes. The fact that they are carrying such different types of cargo makes the calculation modules for an allocation of environmental data different. One of the less complex ones, allocation by deck type, is selected for the calculations of data applied in the ACCEPT system. This method divides the ships emission in the following way:
Like for the RoRo ships, high quality utilisation data is difficult to obtain from the ship operators.
The following vessels are used in the calculations for the ACCEPT system:
The emissions used in the ACCEPT model are rather high since the selected ships are rather small and old. Newer ships are usually less polluting due to larger lane metre capacity as well as cleaner engines. Vessels exist with half the CO2 emission and only a fraction of the NOx emission (e.g. due to SCR de-NOx systems).
The ACCEPT system should be up-dated with more situation specific data supplied from the ship operators carrying out the transports of the investigated vehicles. Capacity utilisation and fuel consumption data should be averaged over a longer period of operations (e.g. one year).
Data for transport with container vessel is given for the transport of the following cargo units:
The following two vessel types are included in the ACCEPT system, see
The vessel emission values were calculated in the same way as for RoRo vessels. Fuel consumption was given for a specified/normal route.
The calculated emissions were allocated to the number of utilised TEU positions. The following values were obtained:
The environmental data per cargo unit can now be calculated. The following results were obtained:
Afterwards standard operating procedures (SOP) for carrying out advantageous implementation of the invention are described in further detail.
The calculation processes are carried out with different data modules.
A preferred embodiment 500 depicted in
The following sequences of activities are to be preferred; dependencies are shown for each step.
The scope is to give easy and potentially secure access to external users (Customer and Suppliers) and internal users (Sales representatives, Quality assurance, Analysts and maintaining of the system).
The access could be preferably done from a company web site, external and internal.
This chapter gives a high level overview on the operation processes of the GO GREEN implementation. There are core process groups that are visualized in a block diagram 600 shown in
A computer which is equipped with software capable of handling Carbon Management represents a preferred hub of the system. Here the accounting of the credits takes place, the demand and supply of credits are matched and carbon credits are retired. This Carbon Management computer is afterwards called CM. The CM is preferably also responsible for the financial and contractual arrangements with the BU on both the demand and supply side.
On the demand side the participating BU sell GO GREEN products to their customers and, in most cases, collect additional revenue for this value added service. They are also responsible for the calculation of the emissions related to the shipments. They are to be compensated by CM according to a method agreed between the BU and CM and verified by an independent third party. The BU report their carbon emissions (and at the same time their carbon demand) to CM on a quarterly basis and pay a previously agreed price for each ton of carbon to CM.
Carbon credits are handled by internal and external abatement projects. Internal projects are represented by alternative vehicles using alternative or (partly biogenic) renewable—fuels. Energy efficiency projects or green energy transport such as solar panels on some of the hubs is also included in the internal carbon portfolio.
It is advantageous to purchase verified emission reductions from voluntary or Kyoto abatement projects.
The focus of this manual lies on those processes, that are relevant for carbon accounting. These processes and the data produced in these processes need to be verified by an independent third party.
The core operation processes related to carbon management are detailed further in the operation process map in
Certain processes and their data need to be verified. Examples of such processes and data include a calculate emissions footprint process 2 (
This chapter describes the individual operation processes that have been outlined in the previous chapter in greater detail.
The description distinguishes between those core processes that are relevant for the carbon accounting and those supplementary processes not relevant for the carbon accounting but necessary for the functioning of the system like the financial accounting processes.
The BU that plans to offer GO GREEN products or services is responsible for specifying emission values for their products or services which should be done according to the steps and the two different methodologies specified in this chapter.
The following steps should be adhered to when introducing new GO GREEN products or services:
The implementation (calculation, sources and values) of these methodologies is described in section 0.
This section describes the general methodology in the bottom-up approach. This methodology is used when systems within the operation (i.e. operational- and billing systems) and provides specific data required for emission calculations. Calculations are made on shipment level and take each movement into consideration.
If this Bottom-up approach is used, it is advantageous to perform a validation test report with the results from the calculation.
The used methodology takes into account all direct emissions related to the transport of the shipments from the fuel combustion in the vehicles including those of the vehicles used by subcontractors. In a first step this relates to carbon emissions. For the carbon emissions from the facilities (hubs etc.) a fixed average value is added. The methodology does neither consider additional emissions in the life cycle of the fuels nor emissions of other greenhouse gases.
For the calculation of the transport emissions per shipment the method distinguishes between emission calculation and emission allocation. Emission calculation is defined as the calculation of the total vehicle emissions related to the use of the different modes of transport, whereas emission allocation relates to the allocation of these emissions to individual shipments. The distinction is necessary because typically a vehicle transports more than one shipment for the different distances and its emissions therefore need to be shared by the individual shipments.
Taking into account the above outlined factors and the division of the shipments into different legs the carbon emissions related to each shipment can be calculated according to the following general principle:
The factors used in this formula for the emission calculation are explained in Table 19.
For further explanation of some of these terms see the glossary.
Depending on information availability different it is possible, to either use generic values or specific values for some of the factors in the calculation formula (mentioned within brackets in the table above).
This section describes the general methodology of the top-down approach. Using this methodology the total carbon emissions of a specific network and all its transports is calculated, based on available overall data. Carbon emissions per product (shipment) are calculated by allocating the relevant share of emissions to each product.
This methodology is based on case-studies, which use different data depending on the data and the specific IT-systems available in the relevant BU and countries. The output of the calculation is an average value for the direct carbon emission per product or service. The emission value shall be calculated ex-ante and reviewed on an annual basis.
The performance of the case study follows the steps below. The most important is to document each step and sources to ensure transparency:
The minimum requirements for the documentation are as follows:
This section and its sub-sections describe the implementation of the general emission calculation methodologies described in section 0 to be used by individual BU for their different products and services.
An overview on the applied methodology per BU and respective GO GREEN products and services is shown in Table 23:
Further products and further BU can be easily included as additional sub-sections.
This sub-section describes the implementation of the general methodology described in sub-section 0 to be used by DHL Express Europe for the TD International product line. For the following products GO GREEN can be chosen as a value added service: TDD, ECX, DOX and WPX.
Table 24 summarizes an explanation of the data types (individual or average) and the data sources (software system, case study etc.) for the variables used in the calculation formula (see also Table 22 and
All default and average values used in the calculation are reviewed on an annual basis by the BU. The result of the review is reported to CM in a suitable format as described in this patent application.
This sub-section describes the implementation of the general methodology described in sub-section 0 to be used by DHL Express UK. for TD domestic and DD international and domestic products. The products offering GO GREEN as a value added service are listed in Table 25 below.
It is possible to automatically create reports stating the direct carbon emissions compensated within the GO GREEN program for each single customer.
The direct carbon emissions are preferably calculated in a top-down approach. An exemplary network/transport process 1100 used for the relevant products is described in
By way of example, the direct carbon emissions for the transport of a single transported physical object are shown for the different sub-processes, especially for the transport according to a leg.
The average emissions for the different products derived with the method described above are shown in Table 26:
All default and average values used in the calculation are reviewed, updated, reported and documented.
Preferably the central control computer performs the gathering and documenting of the relevant data based on data from sub-systems as local hosts. The central control computer performs the calculations to determine carbon emissions from shipments—especially from shipments relating to a certain BU—and ensures that the calculations and data sources are transparent and verifiable for an independent third party. The central control computer checks the plausibility of the results of the calculations in a vertical and horizontal approach.
This sub-section describes the implementation of the general methodology described in section 0 to be used by DHL Express Germany Retail for parcels. This individual implementation of the methodology is valid for the calculation of direct carbon emissions for shipments performed for retail customers in its post offices and other outlets. It is possible to offer GO GREEN to all retail customers. Some of these products are small parcels, afterwards called GO GREEN PlusPackchen.
The GO GREEN parcel will be sold to retail customers via the existing post offices in Germany. The number of GO GREEN PlusPackchen sold can be derived from the billing and accounting systems used.
The direct carbon emissions are calculated in a top-down approach.
The calculations behind each of the sub-processes are described and documented in a file. This file also documents the data sources and assumptions for the different sub-processes.
To account for any uncertainties in the data sources and the calculation the figure of 577 g CO2 per shipment is rounded to
All default and average values used in the calculation are reviewed on an annual basis by the BU. The result of the review is reported to CM in a suitable format, stored and documented.
The central control computer is responsible for gathering and documenting the relevant data from the systems. The central control computer performs the necessary calculations to determine carbon emissions from the shipments and ensures that the calculations and data sources are transparent and verifiable for an independent third party. The central control computer furthermore checks the plausibility of the results of the calculations in a vertical and horizontal approach.
This section describes the quarterly demand reports that are used by the BU to communicate their carbon credit demand for the past quarter to CM.
Details on which data fields are used are described in Table 27 below.
The quarterly demand report consists of a protected Excel file. The structure and format is defined by CM. Changes can only be implemented by CM.
The quarterly report shall be stored by the central control computer on a net-drive
It is preferred to save the quarterly demand reports as read-only files to eliminate the risk of later unintended changes to the data.
Table 27 explains the data fields in the quarterly demand report and shows which BU uses the different data fields.
This section describes the carbon credit demand ledger that is used by CM to aggregate the quarterly demands from different BU. The carbon credit demand ledger is valid only for CM.
The carbon credit demand ledger is a file with several spreadsheets, for example:
The use of these spreadsheets is described in this patent application. The carbon credit demand ledger could for example be created as an Excel file.
The Carbon demand ledger contains preferably the same data fields as the quarterly demand reports by the BU (see Table 27). The additional data fields for use by CM are described in Table 22.
To transfer the data from the quarterly demand report to the carbon demand ledger the following steps are required:
Based on the data in the spreadsheet carbon demand ledger the other spreadsheets provide demand reports, plausibility checks and the data for the certifications.
The carbon demand summary automatically summarizes the demand per BU on a quarterly and annual basis. The summary is for example implemented in an Excel pivot table. The carbon demand summary is used as basis for the quarterly transfers of the aggregated demand into the carbon credit supply ledger for retirement as well as the annual report to the verifier.
After all quarterly bookings have been performed in the carbon demand ledger CM prints and files a hardcopy of the carbon demand summary.
The shipment volume summary automatically summarizes the total volume of shipments per BU on a quarterly and annual basis. The summary is implemented in an Excel pivot table. The data are used for the plausibility check.
The plausibility check demand automatically calculates the average CO2 emissions per shipment on a quarterly and annual basis. The calculation can be used for a plausibility check in a vertical and horizontal approach. The calculation only works properly, if both pivot tables Demand of Carbon (t) on the spreadsheet carbon demand summary and Number of Shipments on the spreadsheet shipment volume summary show the equivalent selections of Operation Unit Name, Preferred Compensation, Quarter and Year. After all quarterly bookings have been performed in the carbon demand ledger CM prints and files a hardcopy of the plausibility check demand.
Carbon Credit Supply Ledger Incl. Retirement (Process-8)
This section describes the carbon credit supply ledger that is used by CM to aggregate the quarterly supply from different internal abatement projects and externally purchased credits as well as to retire carbon credits according to the quarterly demand. The carbon credit supply ledger is valid only for CM.
The carbon credit demand ledger is an Excel file with several spreadsheets:
The carbon supply ledger contains the same data fields as the quarterly supply reports by the BU (see Table 31). The additional data fields for use by CM are described in Table 29.
In the carbon supply ledger both supply and aggregated demand are accounted. Supply is booked with positive values as credit entries. Demand is booked with negative values as debit entries.
Based on the data in the carbon supply ledger the other spreadsheets in this file provide an up-to-date balance for all abatement projects, an overview over the project portfolio and auxiliary calculation for accounting purposes.
The project balance summary automatically summarizes the balances per abatement project on a quarterly and annual basis. The summary is implemented in an Excel pivot table with an additional calculation of the cumulative quarterly balances. The project balance summary is used as basis for the annual report to the verifier. For the second year of operation the balance of the previous year is entered in the project balance summary by hand.
The project portfolio automatically calculates the share of the individual abatement projects in the project portfolio on a quarterly and annual basis. The summary is implemented in an Excel pivot table with an additional calculation of the cumulative quarterly balances.
The auxiliary calculation automatically calculates the share of the total quarterly demand (without preferred method of compensation) that has to be booked on each of the abatement projects in the portfolio. It therefore automatically takes off the quarterly demand data from the demand ledger.
The processes for accounting carbon credits in the carbon credit supply ledger are illustrated and further explained in Table 30
If the carbon supply ledger contains CER (and VER managed in external registries) the relevant amount retired in the supply ledger for the relevant projects need to be retired in the official CDM registry (and the VER registry if applicable) as well. This should be done at least annually, better quarterly, after the internal carbon accounting for the quarter is terminated by CM.
CER refers to rights to emission carbon. VER refers to Verified Emission Reduction data.
The relevant documents for the retirement in the above mentioned registries are filed on net-drives or as hard copies as part of the carbon credit accounting documents.
This section describes the initiation of purchasing internal credits by CM or BU. The description focuses on the perspective of CM.
The purchase of internal credits can be managed by the system according to the invention.
Based on the forecasted supply and demand the central control computer checks regularly (at least quarterly), whether there is a sufficient future supply of credits to balance the expected future demand.
Additionally the project portfolio should have a balanced mix between projects from different geographical areas and different types of technology used for abatement.
In most cases it is possible to avoid a purchase of external emission credits. However, if it is necessary to purchase external emission credits, the following procedure applies.
This section describes the initiation of purchasing external credits by CM.
Whether and when to purchase external credits is decided by CM. In this case a credit purchase agreement between a logistics company and a seller of the external carbon credits is integrated in the carbon management process.
This section describes the documentation needed for internal abatement projects. The section is valid for all internal suppliers (BU) of carbon credits.
It is preferred to check the compliance of the internal projects with the quality criteria for internal projects and to integrate and automate the supply of internal credits.
This section describes the quality criteria used by for internal abatement projects. The quality criteria are valid for the central control computer and all internal suppliers (BU) of carbon credits.
The following quality criteria apply for internal projects:
The relevant information is filed on a net-drive or as hardcopy.
This section describes the quarterly supply reports that are used to communicate carbon credit supply from abatement projects for the past quarter.
The quarterly demand report consists of a protected file. Table 31 explains the data fields in the quarterly demand report.
There are three further data fields in the report for accounting purposes.
This section describes the quality criteria used during the negotiations to purchase external credits for choosing the qualifying projects. The quality criteria are valid for CM and all external suppliers of carbon credits.
For both credibility and practical reasons the same strict standards of additionality as the Kyoto protocol stipulates apply for the credits bought from external projects.
With additionality is generally meant that the project would not have happened unless there was the additional incentive of an extra income stream from the value of the generated credits. The project should not represent operation-as-usual.
Baseline emissions would equal project emissions in this case. Hence a project needs to prove its additionality by showing that is not operation-as-usual.
The credits should at least strive for being VER (Verified Emission Reductions) by an independent third party. Possible standards to be used as the basis for the verification are for example the “GHG Protocol for Project Accounting” by WBCSD/WRI, the “Gold Standard” by a number of NGO (BASE), the “Voluntary Carbon Standard” by IETA and the JI and CDM-Project Cycle defined by the Kyoto Protocol.
From this framework the following quality criteria for external projects are used:
The results of the compliance check are documented.
This section describes the main contents of the SLA between BU owning internal carbon supply projects and CM.
The following carbon management specific aspects should be covered by the SLA:
This chapter describes the measures taken to assure the quality and safety of the data used.
The systems used for gathering data to calculate carbon emissions in the BU underlie a quality assurance system on their own, since they are used for transport control, billing and accounting purposes.
The following measures are taken additionally to ensure the quality and safety of the data:
The following table explains the abbreviations used in this patent application.
Examples for a quarterly demand report for contract customers
/t
Example for a quarterly demand report by DHL Germany Retail for retail customers
/t
Example for a quarterly supply reports for internal abatement projects
/t
In a preferred embodiment of the invention the processing of physical objects takes place in a processing station. In this embodiment, address components that are present on the physical objects are transmitted to an internal data stock. The internal data stock supplies a result address on the basis of the transmitted address components.
Moreover, it is checked whether environmental data were detected. In this case, a selection is made from among the determined environmental data.
Further preferred process steps for the execution of the invention will be explained below. The process steps can be used individually as well as combined with each other, as a result of which the efficiency of the individual process steps is further increased to an especially surprising extent.
A process component that translates into increasing the efficiency of the method with relatively little effort is the implementation of specialized reading software.
A conversion file, which is incorporated into the so-called dictionary of the sorting installation, can implement environmental data. In this manner, if the reading quality is sufficient, then the environmental data are ascertained reliably enough so that the sorting machine is able to sort the physical objects on the basis of the input distribution information (street, optionally house number) and the environmental data.
The environmental data can be applied in different ways, for example, by means of various printing processes. Printing with a fluorescent dye is especially advantageous since this make it possible to especially easily and reliably carry out an optical detection of the target code during a subsequent sorting procedure.
The target code can assume various forms, for example, it can contain environmental data, especially environmental requirement data and other data as for example the complete address information, which is preferably achieved by using an 11-character to 13-character target code with an additional imprint of the postal code in plain text.
However, it is possible to use another code instead of this code, for example, instead of the fluorescent barcode, to use a label with a 4-state code that likewise contains the requisite target information that is in encrypted form and that is applied onto the physical object automatically, preferably in the form of a label. Preferably, the postal code is additionally written on the label in plain text.
In addition to the automated use of the method in processing machines, which are preferably integrated into the normal processing of the physical objects, individual physical objects can also be detected separately, for example, at special processing stations.
Preferably, the individual stations consist of a PC with a monitor and keyboard as well as a label printer as an additional output unit that is controlled by the program and that generates a plain text label or, as an alternative, a 4-state label.
The implementation of the process steps will be explained below with reference to the example of a two-part computer system. However, the invention is not restricted to the especially advantageous case of a two-part computer system presented here.
As a matter of principle, any computer is suitable for carrying out the invention.
The term “computer” is by no means to be understood in a limiting manner. This can be any unit that is suitable for performing computations, for example, a workstation, a personal computer, a microcomputer or circuitry suitable for performing computations and/or comparisons.
Within a preferred embodiment a database is used on a server that takes over the described functions for several processing stations.
The client part is realized in a platform-independent programming language. The use of another programming language is fundamentally possible. The recognizable parts of the data are entered via an input mask. Then a database query is sent by the client to the server.
The server is a powerful computer with several processors and a large main memory. This is necessary in order to achieve very rapid access times.
The data stock consists of the files from a suitable database application containing, at least some environmental data. The design of the database is also configured for rapid access. However, this also means that a great deal of data has to be stored redundantly.
The data accesses are provided by a suitable database application, for example, PL/SQL. Via a PL/SQL procedure, the client receives his result set from the server in the form of data records. The result set is sorted at the client and displayed in a selection list. It can be locally limited by additional entries.
A special feature of the program is that, in a separate list, all environmental data are automatically displayed with the appertaining data for the delivery (post office box, postal code).
A decision module or an operator decides which of the displayed data records (from the normal or, for example, from the special selection list) are applicable in each given case. The decision module or the operator selects this data record and actuates the printing button. Via the locally connected label printer, the appropriate label is printed with the correct address and glued onto the physical object. A decision module is a program module that can observe its environment and that can act largely autonomously. For this purpose, the decision module contains information about the parameters and action instructions that have to be taken into account regarding the procedures. Preferably, the decision module is capable of acting as autonomously as possible.
In a preferred embodiment environmental requirement information attached to the physical object is detected and transmitted to an interface computer. The interface computer contains memory locations for associating the detected images.
The interface computer is connected to a server. The server preferably has the previously presented structure and allows a matching of environmental requirement data with archive able environmental impact data.
The environmental requirement data is detected on the basis of the ascertained image data and by undertaking a database query, or else a data stock query. These queries are made in the form of automated process steps.
This allows obtaining ascertained environmental impact data. This ascertained data is subsequently transmitted to the interface computer.
The interface computer is connected directly or indirectly to the sorting installation.
In a preferred embodiment the interface computer transmits the result data to a result memory of the sorting installation.
The physical objects are preferably associated with the corrected address information by detecting an identification code that identifies them.
Preferably, the identification code was applied onto the physical object in order to allow an association of the new address with the correct physical object.
The identification code makes it possible to associate each of the physical objects with the appertaining environmental requirement data. In an especially preferred embodiment, this is done in that identification codes printed on the physical objects are detected.
It is especially advantageous to print the identification code and/or the environmental requirement data on the physical object.
The printing can be done directly onto the physical object or else by printing a label that is subsequently affixed onto the physical object.
The described implementations of the invention help to analyze environmental impact of transport procedures.
This allows to create a transport system for transporting physical objects, wherein at least one physical object is transported from a sending station to a receiving station, wherein the transport occurs through at least one physical router, wherein the physical router executes a decision about further parameters of transport to another physical router or to the receiving station, wherein environmental data of the transport is calculated and displayed.
Advantageous Processing Rules for Emission calculations are described afterwards:
The basic principle in the calculations is that the emissions reported to the customer should be calculated down to each transport, considering utilization and capacity of the vehicle.
For international shipments the emissions are managed on country level, i.e. that when a border is passed, the emissions are split equally and allocated to each country.
In ACCEPT there is one fundamental calculation method, used for the highest level of accuracy, this model is defined as follows in a 4-step approach:
For each leg of the transport the following is calculated and then summarized in the reports:
The actual calculations can be managed in three different ways, depending on the available data in each country:
The calculations of transports are done as follows, the same model applies for Road and Air. When calculating Road there is today no Fixed Emission Value:
Emissions for customer=((Volume Weight/(Max Load Weight*Fill Factor))*(Fixed Emission Value+Variable Emission Value*Distance))*Fuel Consumption
Fuel consumption is gathered, in this order, from the vehicle, vehicle type or more generic parameters
Calculated as the shipments part of the total available weight capacity and with reference to actual utilization of vehicle
Volume Weight/(Max Load Weight*Fill Factor)
The emission factor is calculated as the sum of fixed emission values and variable values. The fixed values derive from calculating Air transactions and are set to zero for Road calculations. The variable value is depending of the distance, thus the multiplication
Fixed Emission Value+Variable Emission Value*Distance
If data is missing or not correct, ACCEPT either stops the update of this transaction and creates an error message, or uses a less accurate value e.g. using generic Vehicle Type instead the actual vehicle.
Emission from e.g. energy usage in facilities can contribute significantly to the emission footprint of a shipment.
The examples describe two levels for implementing;
Using Level 3 the calculations are gathered from the production systems and the transport work is calculated. This transport work is then multiplied with a more generic emission factor which is set from calculating the emissions from the fleet used in the country.
As an example, figures as stated in the table below are used. The rows represent the different vehicle types used;
These are the basic data used for a first country, e.g. Sweden, where the total transport work is split by vehicle type (and performance) and their part of the total.
Using Level 6 the transactions/data are gathered from the productions systems and the transport work is calculated. This transport work is then multiplied with the specific vehicle used, considering Euro class, fuel consumption, utilization etc, giving a high quality calculation matching the demands from the more demanding customers. Level 6 calculation requires a subsystem that can feed ACCEPT with the relevant data on vehicles such as e.g. the environmental index used.
In advantageous implementations the calculations will vary from level 3 to 6, giving a result that is much better than level 3 but with less quality than a pure level 6. All this depending on the fact that the transactions from production not always meet the need for level 6 reporting, e.g. COSP does not always identify the vehicle.
For specific customers, depending on their routes, a genuine level 6 quality might be achieved if all transactions are detailed enough.
For specific customers, depending on their routes, a genuine level 6 quality might be achieved if all transactions are detailed enough.
Calculating Air emissions are done by from the actual shipment transactions. These transactions include origin and destination, but not the transactions in between. Thus ACCEPT uses a table, CSD, that specifies the different legs in the shipment, as they are planned, deviations from this plan might happen and are not managed by ACCEPT. If there are more than 5 “legs” in a shipment (which is rare) then ACCEPT calculates the last “leg as from last known origin to destination.
Using Level 3 the calculations are gathered from the production systems and the transport work is calculated. This transport work is then multiplied with a more generic emission factor which is set from calculating the emissions from the fleet used in the country or globally.
Using Level 6 the transactions/data are gathered from the productions systems and the transport work is calculated. This transport work is then multiplied with the specific vehicle used, considering air plane type, fuel consumption, utilization etc, giving a high quality calculation matching the demands from the more demanding customers. Level 6 calculation requires a subsystem that can feed ACCEPT with the relevant data on vehicles such as e.g. the environmental index used in a certain region, especially a country, e.g. Sweden,
In real production environment the calculations will vary from level 3 to 6, giving a result that is much better than level 3 but with less quality than a pure level 6. All this depending on the fact that the transactions from production do not always meet the need for level 6 reporting.
Rail emissions are not within the scope for the first release of ACCEPT.
The calculations are though be calculated in a similar way as Road and Air, using NTM methodology and values.
The calculations are calculated in a similar way as Road and Air, using appropriate methodology and values.
The values shown in ACCEPT reports are the following:
For each physical object the value shown can be scaled in order to be more relevant, e.g. it might be more relevant to show emissions in kg instead of gram. This is managed by setting parameters.
Using ACCEPT can involve external interfaces to existing production systems.
For air transports there is a global solution, which can deliver transactions facilitating the implementation of ACCEPT, when one country is up and running, all other countries are easily adhered.
Transactions not accepted in the update are stored in a log file and an error message is created. When the error is corrected they will be updated.
For the road transportations the situation is more complex, most countries have their own system(s), probably requiring a unique interface for each of them. In order to define the interface and estimate the cost, an analysis is done in each country.
ACCEPT is constructed in order to be as flexible as possible; all interfaces are planned for accepting a multiple of input systems. There are different ways how to interface the local production system, whether the major part of interface should be done on the production side or on the ACCEPT side.
The administration of interfaces to several systems is depending of the interface as described above, the aim is that the different production systems automate their deliveries to ACCEPT with ACCEPT administration monitoring the deliveries and updating the system.
Preferred embodiments of the invention allow integrating transportation means, characterized in that they contain means for transmitting environmental performance data of the transportation means to a logical node.
A logical node is any device that can be integrated in a computer network. Nodes can be computers, personal digital assistants (PDAs), cell phones, or various other network appliances.
On an IP (Internet Protocol) network, a logical node is any device with an IP address.
Logical nodes are often times connected by hubs, logical routers, or by a network switch.
The examples are combinable with physical routers, capable of executing a decision about parameters of transport to another physical router or to a receiving station, characterised in that a logical node is assigned to the physical router, wherein the decision is taken according to environmental data.
To carry out these embodiments efficiently it is advantageous to implement at least one computer program, capable of controlling a message for transporting physical objects, wherein the transport occurs through at least one physical router, wherein the physical router executes a decision about further parameters of transport, characterised in that the computer program takes the decision according to environmental data.
For further increasing the efficiency and speed for involving the environmental data, an aspect of the invention concerns a computer program product, characterised in that it contains one of the described computer programs. Preferable the computer program product is loadable in the logical node.
The descriptions for representation of data are always combinable with the examples for routing and/or transporting the physical objects.
Therefore the invention includes information systems as well as routing and transporting systems.
It is absolutely understandable that parts of the invention can be used together or alternatively separately.
It is especially advantageous to use transportation means, the physical router, the computer program or the computer program product according to the invention independently or in combination with one or more of the other parts of the present invention.
This allows obtaining ascertained environmental impact data and using it for a transport optimized with regard to calculated environmental impact data.
| Number | Date | Country | Kind |
|---|---|---|---|
| EP 06 016 417.5 | Aug 2006 | EP | regional |
