Hong Thai Tran
email: hongthai.tran@uts.edu.au

George Feuerlicht
email: george.feuerlicht@uts.edu.au

Optimization of Cloud-based Applications Using Multisite QoS Information

With rapid increase of the use of cloud services, the availability of Quality of Service (QoS) information is becoming of utmost importance to assist application managers in selection of suitable services for their enterprise applications. Due to different characteristics of cloud and on-premise services, monitoring and management of cloud-based enterprise applications requires a different approach that involves the monitoring of QoS parameters such as availability and response time in different geographic locations. In this paper, we propose a multi-site model for the monitoring and optimization of cloudbased enterprise applications that evaluates the availability and response time of cloud services concurrently across different geographic locations. Our preliminary results using eWay and PayPal payment services monitored in eleven sites across four geographic regions indicate that location-based information can be used to improve the reliability and performance of cloud-based enterprise applications.

Introduction

SOA (Service Oriented Architecture) is evolving towards a more flexible, dynamically scalable cloud-based computing architecture for enterprise applications. Typically, multiple cloud and on-premise services are composed using different protocols and integration methods to provide the required enterprise application functionality. As cloud services are sourced from different cloud providers their QoS (Quality of Service) characteristics can substantially differ depending on the geographical location and on the provider cloud infrastructure. While most cloud service providers publish QoS information on their websites, it often does not accurately reflect the values measured at the consumer site as the performance of cloud services is impacted by numerous factors that include dynamic changes in network bandwidth and topology and transmission channel interference [START_REF] Wenmin | A History Record-Based Service Optimization Method for QoS-Aware Service Composition[END_REF]. Additionally, changes in provider internal architecture and method of service delivery can significantly impact on QoS characteristics of cloud services. Consequently, consumer monitoring and optimization of the runtime behaviour of cloud services has become critically important for the management of enterprise applications [START_REF] Safy | Runtime Monitoring of SOA Applications: Importance, Implementations and Challenges[END_REF].

Service monitoring is a run-time activity that involves recording the values of response time, availability and other non-functional service parameters in order to enable predictive analysis and proactive service management. Service monitoring and service management in cloud computing environments presents a particular challenge to application administrators as the enterprise application is dependent on the performance and availability of third-party cloud services. The traditional approach to QoS monitoring is based on continuously sending test messages to critical services to check their availability and performance. This approach is not suitable for the monitoring of cloud services as it increases service costs and generates unnecessary data traffic.

Monitoring and optimization of QoS of cloud services presents an important and challenging research problem. Although some research work on monitoring of QoS characteristics of cloud services is available in the literature, there is currently lack of detailed information about the assessment of run-time behaviour of cloud services that includes location-based QoS information [START_REF] Aceto | Cloud monitoring: A survey[END_REF], making informed decisions about the selection and composition of cloud services difficult in practice [START_REF] Lu | A multi-criteria QoS-aware trust service composition algorithm in cloud computing environments[END_REF][START_REF] Noor | Analysis of web-scale cloud services[END_REF].

In our earlier work we have described the features of the Service Consumer Framework (SCF) designed to improve the reliability of cloud-based enterprise applications by managing service outages and service evolution. We have implemented and experimentally evaluated availability and response time characteristics of payment services (PayPal and eWay) using three separate reliability strategies (Retry Fault Tolerance, Recovery Block Fault Tolerance, and Dynamic Sequential Fault Tolerance) and compared these experimental results with theoretically predicted values [START_REF] Tran | Improving Reliability of Cloud-Based Applications[END_REF].

In this paper we extend this work by focusing on improving the estimates of availability and response time of cloud services by introducing location-based QoS information. We monitor QoS characteristics of eWay and PayPal services across eleven locations in four geographical regions to obtain a more accurate estimate of response time and availability for specific deployment locations of consumer enterprise application. We collect the QoS information independently of the information published by cloud service providers by recording payment transaction log data in a monitoring database. In the next section (section 2) we review related literature dealing with monitoring the performance of cloud-based services, and in section 3 we discuss service optimization using multi-site monitoring. Section 4 describes our experimental setup for multi-site monitoring of cloud services and gives experimental results of availability and response time for eWay and PayPal payment services measured at eleven geographic locations. Section 6 contains our conclusions and proposals for future work.

Related work

Optimization techniques to improve reliability and performance of enterprise applications that include fault prevention and forecasting have been the subject of research interest for a number of years [START_REF] Tsai | On Testing and Evaluating Service-Oriented Software[END_REF]. Such techniques have been recently adapted for web services and cloud-based enterprise applications. Using redundancy-based fault tolerance strategies, Zibin and Lyu [START_REF] Zibin | A Distributed Replication Strategy Evaluation and Selection Framework for Fault Tolerant Web Services[END_REF] propose a distributed replication strategy evaluation and selection framework for fault tolerant web services. Authors compare various replication strategies and propose a replication strategy selection algorithm. Adams et al. [START_REF] Adams | An introduction to designing reliable cloud services[END_REF] describe fundamental reliability concepts and a reliability designtime process for organizations, providing guidelines for IT architects to mitigate potential failures of cloud-based applications. Developing reliable cloud-based applications involves a number of new challenges, as enterprise applications are no longer under the full of control of local developers and administrators. In response to such challenges, Zibin et al. [START_REF] Zibin | Component Ranking for Fault-Tolerant Cloud Applications[END_REF] present a FTCloud component ranking framework for fault-tolerant cloud applications. Using structurebased component ranking and hybrid component ranking algorithms, authors identify the most critical components of cloud applications and then determine an optimal fault-tolerance strategy for these components. Based on this work, Reddy and Nalini [START_REF] Reddy | FT2R2Cloud: Fault tolerance using time-out and retransmission of requests for cloud applications[END_REF] propose the FT2R2Cloud framework as a fault tolerant solution using time-out and retransmission of requests for cloud applications. FT2R2Cloud measures the reliability of software components in terms of the number of responses and throughput. Authors propose an algorithm to rank software components based on reliability as calculated using number of service outages and service invocations over a period of time.

Other authors focus on QoS optimization, for example Deng and Xing [START_REF] Deng | A QoS-oriented optimization model for web service group[END_REF] proposed a QoS-oriented optimization model for service selection. This approach involves developing a lightweight QoS model, which defines functionality, performance, cost, and trust as QoS parameters of a service. Authors have verified the validity of the model by simulation of cases that show the effectiveness of service selection based on these QoS parameters. Leitner et al. [START_REF] Leitner | Cost-based optimization of service compositions[END_REF] formalize the problem of finding an optimal set of adaptations, which minimizes the total cost arising from Service Level Agreement (SLA) violations and the cost of preventing the violations. Authors present possible algorithms to solve this complex optimization problem, and describe an end-to-end approach based on the PREvent (Prediction and Prevention based on Event monitoring) framework. They discuss experimental results that show how the application of their approach leads to reduced service provider costs and explain the circumstances in which different algorithms lead to satisfactory results. Other authors have focused on predicting future QoS values using service performance history records. Wenmin et al. [START_REF] Wenmin | A History Record-Based Service Optimization Method for QoS-Aware Service Composition[END_REF] present a history record-based service optimization method, called HireSome that aims at enhancing the reliability of service composition plans. The method takes advantage of service QoS history records collected by the consumer, avoiding the use of QoS values recorded by the service provider. Authors use a case study of a multimedia delivery application to validate their method. Lee et al. [START_REF] Lee | On quality of service optimization with discrete QoS options[END_REF] present a QoS management framework that is used to quantitatively measure QoS and to analytically plan and allocate resources. In this model, end users quality preferences are considered when system resources are apportioned across multiple applications, ensuring that the net end-user benefit is maximized. Using semantically based techniques to automatically optimize service delivery, Fallon and O'Sullivan [START_REF] Fallon | The aesop approach for semantic-based end-user service optimization[END_REF] introduce the Semantic Service Analysis and Optimization (AESOP) approach and a Service Experience and Context COllection (SECCO) framework. The AESOP knowledge base models the end-user service management domain in a manner that is aware of the temporal properties of the services. The autonomic AESOP Engine runs efficient semantic algorithms that implement the Monitor, Analyze, Plan, and Execute (MAPE) functions using temporal properties to operate on small partitioned subsets of the knowledge base. A case study is used to demonstrate that AESOP is also applicable in the Mobile Broadband Access domain.

So far only a very limited attention has been paid to using location-based QoS information for the optimization of cloud-based enterprise applications.

Service Optimization Using Multi-Site Monitoring

Service optimization is concerned with continuous service improvement and aims to optimize performance and cost of business services. Consider, for example, the situation illustrated in Figure 1 that shows an Online Shopping Check Out service that includes a cloud-based payment gateway. At design time, the service consumer needs to select a suitable payment service to integrate into the business workflow ensuring that both the functional and non-functional requirements are satisfied. Making this selection decision requires the knowledge of QoS parameters at the site where the enterprise application is deployed. Typically, both the service provider and service consumer perform service monitoring independently, and both parties are responsible for resolving service quality issues that may arise. Service providers maintain transactions logs and make these logs available to service consumers who can use this information to calculate service costs and to estimate service QoS. Provider QoS data is collected continuously at the provider site irrespective of any connectivity issues and includes information about planned and unplanned outages. However, the QoS values published by service providers may not accurately reflect the values measured at the service consumer site as With some global cloud service providers, the actual location from which the service is delivered may not be known to service consumers, making it difficult to optimize the performance of the enterprise application based on QoS values published by the provider. The QoS values measured at the consumer site are impacted by connectivity issues, and while these values may not fully reflect provider site QoS measurements they are important indicators of enterprise application performance. Multi-site monitoring can be used to overcome the limitations of single-site (provider or consumer) QoS monitoring by mapping the behaviour of cloud services across different sites and geographical regions. We argue that in order to fully optimize cloud service selection and deployment and to ensure that the non-functional requirements are met at runtime, the service consumer needs to know the runtime QoS values of cloud services as measured in different geographic locations. To accomplish this, we propose a model that uses a centralized monitoring database to collect service QoS data from multiple service consumer locations and making this data available for analysis by service consumers (Figure 2). This can be achieved by collaboration among different service consumers who record their local monitoring data in a global QoS database and share this information with other consumers of cloud services. The implementation of such a shared QoS monitoring database would enable accurate real-time QoS analysis and real-time notifications of QoS issues. Runtime performance information (i.e. response Fig. 2. Multi-site cloud service monitoring time, availability and various types of error messages) recorded in the database can be used by application administrators to monitor service utilization, plan maintenance activities, and to perform statistical analysis of response time and throughput for individual cloud services.

Enterprise application optimization strategies

Optimization of enterprise applications that use cloud services may involve a number of different strategies that range from using alternative cloud services to migrating the servers that run the application to a different cloud infrastructure. With increasing availability of alternative cloud services with equivalent functionality, service consumers can chose services to use in their enterprise applications based on the cost and QoS characteristics. This may involve deployment of a new version of an existing service or replacement of the service with an alternative from a different provider, if the original service becomes obsolete or too costly. Service consumers can also optimise application performance by re-locating the application to a different cloud infrastructure selecting a more suitable geographic location, taking into account both enduser connectivity and connectivity to third-party cloud services. Finally, QoS characteristics of cloud-based enterprise applications can be improved by using various reliability strategies, re-configuring cloud services to provide higher levels of fault tolerance [START_REF] Tran | Improving Reliability of Cloud-Based Applications[END_REF]. These fault tolerance strategies include Retry Fault Tolerance (RFT), Recovery Block Fault Tolerance (RBFT) and Dynamic Sequential Fault Tolerance (DFST) strategies. Using RFT strategy, cloud services are repeatedly invoked following a delay period until the service invocation succeeds. RFT helps to improve reliability, in particular in situations characterized by short-term outages. The RBFT strategy relies on service substitution using alternative services invoked in a specified sequence. This failover configuration includes a primary cloud service used as a default (active) service, and stand-by services that are deployed in the event of the failure of the primary service, or when the primary service becomes unavailable because of scheduled/unscheduled maintenance. The DFST strategy is a combination of the RFT and RBFT strategies that deploys an alternative service when the primary service fails following RFT retries [START_REF] Zheng | Selecting an Optimal Fault Tolerance Strategy for Reliable Service-Oriented Systems with Local and Global Constraints[END_REF]. The choice of an optimal strategy for the deployment of cloud services must be based on in-depth knowledge of QoS characteristics including their dependence on the geographical location.

Experimental setup for multi-site monitoring

In order to evaluate the proposed location-based QoS approach to optimization of cloud-based enterprise applications we have implemented an experimental multi-site monitoring environment for two payment services: PayPal Pilot service (pilotpayflowpro.paypal.com) and eWay Sandbox (https://api.sandbox.ewaypayments.com). The QoS data was collected using Amazon Elastic Compute Cloud (AWS EC2) servers deployed at eleven sites (Mumbai, Seoul, Singapore, Sydney, Tokyo, Frankfurt, Ireland, Sao Paulo, California, Oregon and Virginia) across four different geographic regions (Asia Pacific, Europe, South America and the US). The monitoring database was implemented using Microsoft SQL Server Amazon Relational Database (AWS RDB). The QoS data was collected in each site by monitoring payment transactions and removing private data such as customer information before recording the information in the monitoring database. Simulating over 200,000 payment transactions initiated by 300 users, payment services were invoked using the SCF (Service Consumer Framework) payment service adaptor that logs the service name, location, start time, end time, result, and error code for each payment transaction [START_REF] Feuerlicht | Service consumer framework: Managing Service Evolution from a Consumer Perspective[END_REF].

The payment service response time for a transaction ( ) was calculated as:

= T -T ( 1
)
where T is the end time of transaction and T is the start time of a transaction, and the average response time ( ) of a service was calculated as:

= ∑ (2)
where n is number of transactions, and T is response time of a transaction in equation [START_REF] Wenmin | A History Record-Based Service Optimization Method for QoS-Aware Service Composition[END_REF]. Similarly, an inactive time or downtime of a service ( ) is calculated as:

= T -T

where T is the start time of a failed transaction and T is the start time of the next successful transaction. Then, the availability of a service ( ) is calculated as:

= T -T (4)

= ∑ (5) = 1 - ( 6
)
where D is the duration of test period that is calculated using the end time of last transaction (T ) and the start time of first transaction (T ).

is probability of failure of a service, and is a downtime in equation ( 3) and is the availability of a service. Table 1 shows the response time of eWay and Paypal payment services as measured in different geographical locations over the monitored period 20 th to 28 th August 2016. The table shows that the response time of the eWay service is better (in most cases less than half) than the response time of the PayPal service, while the availability of both services is approximately the same. Both response time and availability are influenced by two major factors: provider QoS characteristics and the reliability of the network connection. In order to optimize the consumer side QoS characteristics it is important to identify which of these factors plays a dominant role. If network connectivity is the dominant factor that impacts on service quality, then using the RFT fault tolerance strategy described in section 3.1 above may improve consumer side QoS, but only for situations characterized by short-term outages or latency fluctuations. When network connectivity suffers from long-term outages, the solution may involve migrating the service to a different cloud infrastructure in a different geographical location. However, if network connectivity is not a dominant factor and QoS degradation is caused by provider related issues, then RBFT and DFST fault tolerant strategies may provide a solution by substituting alternative services at runtime. In order to differentiate between network connectivity and cloud service provider issues we analyse the level of dependence between QoS parameters for the two payment services (eWay and PayPal) at each location by calculating the correlation coefficient for response time and availability. High level of dependence indicates that both payment services fail or suffer from increased response time at the same time, identifying network connectivity as the main source of the problem. Low levels of correlation indicate independent modes of failure for the two payment services, pointing to the ser-vice provider as the cause of QoS fluctuations. Table 2 shows the values of correlation coefficients of eWay and PayPal payment services calculated for different locations. The correlation coefficient ( , ) [START_REF]CORREL function[END_REF] of response time between eWay and PayPal services is calculated as:

( , ) = ∑( ! """ )( ! """" ) #∑( ! """) $ ∑( ! """") $ [START_REF] Tsai | On Testing and Evaluating Service-Oriented Software[END_REF] where % is response time for eWay transaction, & is the response time for a concurrent PayPal transaction, ' ( is the average response time of the eWay service and & """ is the average response time of the PayPal service. The correlation coefficient ( , ) for the availability of eWay and PayPal is calculated as:

( %, &) = ∑( ! """" )( ! """" ) #∑( ! """") $ ∑( ! """") $ [START_REF] Zibin | A Distributed Replication Strategy Evaluation and Selection Framework for Fault Tolerant Web Services[END_REF] where % is average availability of the eWay service, & is average availability of the PayPal service computed for one hour, ' ( is the average availability of eWay service during the monitoring period, and & """" is the average availability of PayPal service during monitoring period. It is evident from the low correlation coefficient values in Table 2 that the underlying factors affecting response time and availability of the two payment services are mutually independent over the monitored period. As the two payment services share the same network connections, this indicates that the source of QoS variability is the service provider system, rather than the network. This implies that improved QoS values may be achievable by deploying RBFT and DFST service substitution fault tolerant strategies [START_REF] Feuerlicht | Service consumer framework: Managing Service Evolution from a Consumer Perspective[END_REF]. We also note that in an environments characterized by reliable low latency network connectivity the QoS values observed at the service consumer site will approximate those published by the service provider. Figure 3 and Figure 4 show the hourly average response time and availability values for eWay and PayPal services during the monitored period between 20 th and 28 th August 2016 for eleven geographic locations across the globe. Figure 3 shows that the response time of eWay services is generally better than for PayPal and that the re-sponse time of PayPal deployed in the US and Europe is better than those deployed in Asia Pacific. Figure 4, shows that the availability of both services varies from 98.8% to 99.8% with PayPal availability slightly better than that of eWay.

Conclusion

In this paper we have argued that consumer-side monitoring of QoS characteristics of cloud services is essential to enable service consumers to make informed decisions about service selection at design-time, and to maintain good run-time performance of cloud-based enterprise applications. Service consumers need to supplement QoS information published by cloud providers with data obtained independently using consumer side monitoring taking into account location-based information, as the QoS values measured at the consumer deployment site (i.e. at the site where the enterprise application is running) may vary from those published by cloud service providers. Our results obtained using AWS (Amazon Web Services) platforms deployed in eleven sites across four geographic regions to monitor eWay and PayPal payment services indicate that both services achieved availability values above 99.9% during most of the measurement period 20 th to 28 th August 2016. It is evident from the low correlation coefficient values that the underlying factors affecting response time and availability of the two payment services are mutually independent. As the two payment services share the same network connections, this indicates that the source of QoS variability is the service provider system, rather than the network. This implies that improved QoS values may be achievable by deploying RBFT and DFST service substitution fault tolerant strategies. Using a combination of QoS information published by cloud service providers and QoS data measured at different geographic locations by service consumers, improves the understanding of performance and reliability trade-offs and can facilitate the selection of more effective optimization strategies.

In our future work we plan to collect QoS data over an extended period of time to give more reliable estimates of service availability and response time. We also plan to make our monitoring database publicly available to cloud service consumers to enable sharing of QoS information and to promote a collaborative effort with the aim to improve the accessibility of cloud QoS information.

Fig. 1 .

 1 Fig. 1. Online Shopping Check Out optimization scenario

Fig. 3 .Fig. 4 .

 34 Fig. 3. Hourly average response times of eWay and PayPal services (20 th to 28 th August 2016)

Table 1 .

 1 QoS data for eWay and PayPal payment services

	Region	Location	Service	Number of Transaction	Number of Fails	Average Time (s) Response	Availability
			eWay	8328	52	1.48	99.37%
		Mumbai	PayPal	8328	43	3.37	99.47%
	Asia Pacific	Seoul	eWay PayPal	9599 9601	55 53	1.25 2.71	99.42% 99.44%
		Singapore	eWay	8900	57	1.33	99.35%

Table 2 .

 2 Response time and availability correlation coefficients for eWay and PayPal

	Region	Location	Response Time	Availability
	Asia Pacific	Mumbai	-0.0317	-0.0229
		Seoul	0.0896	-0.0861
		Singapore	0.0027	0.0868
		Sydney	0.0947	0.0577
		Tokyo	-0.0867	0.1273
	Europe	Frankfurt	-0.1168	-0.2012
		Ireland	-0.0169	0.0536
	South America	Sao Paulo	0.0648	0.0415
	US	California	0.0924	-0.0612
		Oregon	-0.0331	-0.0275
		Virginia	-0.0523	0.0137


Petr Doucek
email: doucek@vse.cz

Milos Maryska
email: maryskam@vse.cz

Lea Nedomova
email: nedomova@vse.cz

The Reference Model for Cost Allocation Optimization and Planning for Business Informatics Management

Keywords:

The proposed conceptual model deals with two areas -Cost Allocation and Planning for Management of Business Informatics. This paper shows some limitations of the model, its architecturethe individual layers of the model, key principles of cost allocation on which the proposed model is based, and factors which must be taken into account during the development and subsequent implementation of the model. Practical experience with model´s implementation in business are discussed. In conclusion, there are several ideas for the future development of the reference model.

Introduction

The main target of the company is achieving its targets and especially achieving profits [START_REF] Dopson | Linking Cost-Volume-Profit Analysis With Goal Analysis in the Curriculum Using Spreadsheet Applications[END_REF][START_REF] Halkos | International Competitiveness in the ICT Industry: Evaluating the Performance of the Top 50 Companies[END_REF]. Management requires exact information about company's economic situation to be able to set paths to these aims [START_REF] Harindranath | ICT in a Transition Economy: The Case of Hungary[END_REF][START_REF] Young | Goals and Goal-Setting[END_REF]. This information is presented by measures [START_REF] Ling | Key Performance Indicators for Measuring Contractors' Performance[END_REF][START_REF] Martin | On measuring company performance within a supply chain[END_REF][START_REF] Sarker | A comparison of existing grouping efficiency measures and a new weighted grouping efficiency measure[END_REF][START_REF] Sauka | Measuring the competitiveness of Latvian companies[END_REF].

Measuring results and performances have a long tradition [START_REF] Chen | Measuring Information Technology's Indirect Impact on Firm Performance[END_REF][START_REF] Manning | Measuring results in development: the role of impact evaluation in agency-wide performance measurement systems[END_REF]. Rapid development in this area is visible especially in last ten years [START_REF] Thompson | ICT Research in Africa: Need for a Strategic Developmental Focus[END_REF] and this development can be split into two groups. The first group is especially about development in the area of norms and processes how the measuring should be realized and the second group is about development of tools for measuring results and performances with the support of information and communication technologies (ICT) [START_REF] Manning | Measuring results in development: the role of impact evaluation in agency-wide performance measurement systems[END_REF].

Measuring of results and performance is usually covered with Performance Measurement System (PMS) that helps organizations with a task to achieve their goals and stay competitive by measuring and managing their efficiency and effectiveness of their actions [START_REF] Neely | Performance measurement system design: A literature review and research agenda[END_REF] and that covers both of above mentioned groups. Organizations feel that PMS is contributing them to achieve their success but they face problems implementing it University of Economics in Prague, Faculty of Finance and Accounting [START_REF] Petera | Strategic Performance Measurement Systems Implemented in the Biggest Czech Companies with Focus on Balanced Scorecard -An Empirical Study[END_REF].

This feeling is based on necessity of information not only about the company as a whole, but also details information about each of company's parts. These necessities are closely connected with company's owners' requirements on providing information about company's economic situation. One of the most important factors that is influencing availability of information is quality of the Business Informatics.

One of the general approaches to creating and defining of PMS is Corporate Performance Management (CPM), which is a management concept that describes processes, methods, metrics and systems that are needed for performance management of a company [START_REF] Gartner | Corporate Performance Management: BI Collides With ERP[END_REF]. The main goal of CPM is allowing of measuring and management of performance of a company or its parts and helps to company to achieve its goals.

Corporate Performance Management is an umbrella term that describes the methodologies, metrics, processes and systems used to monitor and manage the business performance of an enterprise.

Performance management means the process of collection, analysis and/or reporting of information which are relevant to efficiency to individual, group, organization unit, system or their parts [START_REF] Upadhaya | Association between performance measurement systems and organisational effectiveness[END_REF]. It could contain also the process and strategy investigation or investigation of technological procedures and phenomenon in order to identify if their outputs are in relevance to organization´s intentions and goals. The core of performance management is the added value production in chain "Data -Value -Metric -Measurement -Indicator -Information". This chain must function consistent in order not to produce distorted information.

Performance management can be understood as performance management in the complex organization´s management system [START_REF] Berry | Emerging themes in management control: A review of recent literature[END_REF]. In this context, is performance management decision and executive making process based on obtained data and information in order to influence achieved outputs and results. For consistent performance management is not sufficient only the performance measurement system [START_REF] Flapper | Towards consistent performance management systems[END_REF]. The condition of consistence must be also fulfil between measurement (what and how is measured) and management (how are measurement interpreted, what is the goal and how are results used).

This paper aims to present a conceptual reference model for cost allocation and planning for efficient management of corporate informatics (REMONA). We have found out that these areas of performance management in business informatics should be covered by ICT support but these are not available [START_REF] Harindranath | ICT in a Transition Economy: The Case of Hungary[END_REF], [START_REF] Berry | Emerging themes in management control: A review of recent literature[END_REF], [START_REF] Voříšek | Management of business informatics modelprinciples and practices[END_REF]. During another research we found out that our model should be based on the principles of Corporate Performance Management (CPM) that is general approach to PMS. An inseparable part of the presentation is holding a scholarly discussion about the presented model to obtain feedback and opinions on its design from the academic community and from end users. The REMONA model is proposed as part of an academic project of the Faculty of Informatics and Statistics at the University of Economics in Prague in association with the companies Profinit, s. r. o. and AM-line.

The design of the model follows the Design Science Research approach [START_REF] Hendl | Kvalitativní výzkum[END_REF] that is extended for additional scientific approaches:

 Case studies and qualitative research [START_REF] Maryska | Referenční model optimalizace nákladove alokace a plánování pro řízení podnikové informatiky (habilitační práce)[END_REF][START_REF] Peffers | A design science research methodology for information systems research[END_REF] we realized 7 business projects and consultations with Chief Financial Officer in different companies during year 2010-2014 that help us with formulation of lack of current solution and gaps that are feel by managers.

 Analysis of current state of the art that is proved by cited literature and synthesis and deduction that help us with identification and formulation of the problem and project goals,  Design and development of the model,  Final solution was tested by way of two case studies in selected international companies [START_REF] Yin | Case Study Research: Design and Methods[END_REF].

The REMONA model

The proposed model identifies key dimensions and indicators and interconnects them within designed analytical cubes. REMONA is designed to be easily integrated into a company and easily configured, which enables it to quickly tailor to the needs of a specific company.

The REMONA model is based on the principles of Corporate Performance Management and Business Intelligence. The aim of the model is to offer a solution to two key corporate tasks, 'cost allocation management' and 'planning'. This solution is inextricably connected with the tasks of analyses and in particular, what-if analyses. For both tasks the model comprises key 'Dimensions', 'Metrics', 'Drivers' and 'Activities', which are addressed as part of corporate informatics. Another requirement for the model is the possibility of its rapid and easy adaptation to a specific company in which it will be implemented. This is achieved in the case of the REMONA model by its logic being implemented as much as possible through appropriate links between data cubes and related dimensions.

To get the full picture we should add that in the case of specific companies or specific allocation rules or analyses of profitability we are ready to make required changes directly in the reference model (solution code) and add new findings to the original model through system feedback.

The proposed model is based on basic requisites, limitations and requirements which must be fulfilled to ensure that REMONA can be easily and quickly implemented in a company. The model design is based on the following:  The overall design of the model must be a general one so that it can be tailored to the needs of a target organization.  The proposed model must support easy and quick integration into corporate architecture.  The model will be created in such a way that modifications can be made primarily through configuration of the system, although it is possible that some functionality may have to be developed to meet specific requirements.  During the preparation of the model the necessary dimensions and key metrics must be identified for tasks carried out in a given area.

When designing the model and subsequent implementation of the system it is necessary to answer some key questions, which have to be taken into consideration as they affect the preparation of the proposed model:  What are current and expected main problems in economics and management of development and operation of corporate informatics and what the priorities of the solution?  Are some of the standard methodologies (ITIL, CobiT) or proprietary methodology or model used in the management of informatics?  Is the management of corporate informatics based on the management of services and service level agreements?  What key metrics are required for the management of the economics of the system for corporate informatics? Are any in use at present?  Is there documentation of the management of corporate informatics and database management from which data can be obtained? Are there data in them that could be used to design and fulfilment of metrics and dimensions?  Has an analysis been carried out of the level of ripeness of processes of corporate informatics management and what are the results?  How high a level of detail will be necessary for analytical tasks in the management of economics of corporate informatics?  How are costs of PI monitored?  What is the place of cost analysis in corporate informatics management?

The proposed REMONA model is designed to permit easy and quick adaptation (modification) of the solution according to the character of the answers to these questions by parameters without high costs of additional alterations.

General Overview

The REMONA model is solved by the authors in following areas: The Tasks describes issues that are solved with the model and dimensions and metrics support solving of these issues from multidimensional point of view. Business Tasks can be described as predefined processes that are using dimensions and metrics defined for the model and these dimensions and metrics can be used for parameters of the REMONA model. These three business task were selected because cost allocation, planning, and profitability is growing in importance. The market and the economy are undergoing a negative economic development. It is in such periods that managers demand accurate, detailed and up-to-date information not only about the company as a whole but also about its individual parts [START_REF] Král | Manažerské účetnictví[END_REF]. Key activities and goals according to [START_REF] Dimon | Enterprise Performance Management Done Right: An Operating System for Your Organization[END_REF][START_REF] Turban | Information Technology for Management: Transforming Organizations in the Digital Economy[END_REF], [START_REF] Young | Goals and Goal-Setting[END_REF] include at present:  Every company tries to get maximum return on each investment and clearly identify, and in many cases calculate, the benefits of investments.  Companies try to minimize or eliminate activities and processes which do not generate the required value.  Companies struggle against changing economic conditions.  Measuring and managing a company as a whole and company informatics as one of its parts is a phenomenon being closely monitored.  Proving that investments are warranted (for example, in ICT) and proving the achievement of expected or required results.


The application REMONA can be described as a software that is supplemented for analytical and operational manuals. The REMONA model contains the design of data model only but the REMONA model contains developed model with user interface in the form of reporting. The REMONA model is designed in the context of easy improvement. We expect that different companies requires different dimensions and metrics. Our design contains the general dimensions and metrics only and these can be supplemented by other users. From these reasons we selected IBM Cognos Express as a platform that provides the best environment for easy improvement.

Business Architecture

The architecture can be described from several views with different degree of detail and elements describing the model.  primary data sources,  data integration -Data Stage (addressing questions of data pumps (ETL) and data quality),  core of data warehouse and data martpartly addressed in REMONA,  application layer and user interface layer (object of REMONA),  a metadata layer passes through all the layers which is of key importance for end users as it guarantees a standard language and description of all indicators and attributes which are part of REMONA and the other layers of the company information system.

The architecture of the model shown in the following picture Fig. 2 is based on the traditional architecture of a BI solution and modified for the purposes of the model with the aim of allowing its integration into the architecture of an ordinary organization. The picture shows in detail a view of the individual components of the architecture described above as part of data warehouse and application layer.

A layer of application tools ('Application Platform) contains the business logic of the proposed REMONA model which reads in data from a prefabricated data model.

Business Process Management and Collaboration

End-User Experience

Applications

Data Management Layer -Data Warehouse

The data model and the data warehouse developed according to it must cover the needs implied from the analytic tasks to be performed over it.

The conceptual model is divided into four compact sections, which are further detailed up to the level of physical data model, which is implemented in the selected database technology. The conceptual model is divided into the areas "Finance and Management Accounting", "Production Entity", "Cost Allocation Entity" and "Other Entity" [START_REF] Maryska | Reference model of business informatics economics management[END_REF]. Each of these areas covers a specific field.

Application Layer

The application is the most important part of the REMONA model. This is the operating part of the whole model. The application layer contains logic of the REMONA model. This logic is based on rules and processes that are processing three defined business tasksprofitability, planning and cost allocations. We have defined several multidimensional cubes for each of these business tasks. Multidimensional cubes allows processing of calculation steps defined in processes defined for each of business tasks.

We have divided cubes into four groups:

 parametric (prefix RF -Rates and Factors),  calculating (prefix Lulookup),  data cubes (prefix C -Cube),  data cubes -Historical (prefix CH -Cube History).

Each of multidimensional cubes contains one dimension with metrics and at least one standard dimension that is used for analyzing of data in the cube. We defined relations among cubes that enables to process data in on-line mode. Data are pre-processed during loading in batch mode. This approach makes solution faster.

User Interface Layer -Reporting

In the model design, we expect the use of two main types of presentation and analyticpresentation layers:

 Native tools and the selected environment, i.e., the tool Cognos Express/Cognos TM1.  The tool Microsoft Excel.  The first group of tools provides full functionality implied by the fact that these are native tools. As for the tool Microsoft Excel, the functionality of the solution is provided by a plug-in module, which implements in the tool Microsoft Excel full functionality of the systems Cognos Express/Cognos TM1.

Results and Implementation Experience

The REMONA model was implemented in two international companies, the first one with headquarter in USA and the second one with headquarter in Germany.

The target of the first implementation (in USA) was verify that model is possible to implement in big company and investigate what is missing in the model and what should be improved or changedespecially in metrics and dimensions.

Model REMONA was adjusted according to the experiences from the first implementation. Adjusted model was implemented in selected international company in Germany.

The first implementation was carried out over the MS SQL Server 2012 database in which the data warehouse of the REMONA model was implemented. The second used system was IBM Cognos Express and Microsoft Excel 2010 as a reporting tool. The solution was prepared over data for 1 year of the company's life.

Implementation was split into 5 phases:

 Identification of the reason for introducing the REMONA Model to the target company, business requirements and setup of the project  Analysis  Draft data warehouse and ETL  Implementation of ETL and the REMONA Model  Testing and verification of the setup Based on the results the authors identified that one of the researched projects is currently loss-making. Based on the results authors find out, that:  high price of the accommodation of employees which are at the site of the solution of the project which is not covered by the customer,  higher share of time spent at the site as opposed to the agreement, where the plan of the presence of employees at the site was lower (by 40%),  higher travel expenses and board caused by the same reasons stated in the previous point.

The yield for the services provided is not stated as the cause which corresponds to the agreed rate. The error of low profitability or loss, as the case may be, is caused by badly calculated costs for the project and the inadequate price for the provision of services.

The second implementation provides information about efforts that have to be invested into implementation in small company with DWH that have 85 tables. The efforts were 45 man-days from which 22 man-days was implementation of standard solution (analysis of target environment and processes and customization) and 23 mandays was adjustment of REMONA (development new functionality and new reports)

The savings from the second implementation were defined in areas as follows:

 Monthly financial statements are available from all subsidiaries.  Real-time reporting over all subsidiaries, for example from point of view (Travel costs, drawing of project budget, employees workload etc.).  Unified processes for evidence without dependency on human factor.  Saving of 1.2 FTE (full time equivalent) over all subsidiariesautomatized reporting.

All of these savings proved that the solution provides effects to companies that are using this solutions and pilot implementation in both companies proved that implementation is possible and not so difficult.

Conclusions

CPM is very significant activity among business activities and its importance keeps growing. It is especially very important activity from the point of view of company managers.

Business economics management cannot succeed without adequate procedures. If this type of management is not successful, company top management cannot be expected to support it and to consider it one of key departments keeping entire business vital. If it is not possible to prove benefits, company management shall see it as a simple cost item that should be minimized as much as possible.

The model provides effects in several areas. For business practice the REMONA model and its implementations proved that:

 The REMONA model is adjustable to the requirements of the companyconfiguration is especially in the area of ETL that are reading data from the source systems (DWH) and loading it into the REMONA, code lists, dimensions, metrics etc.  The model takes into account current trends in the area of Business Intelligence, Corporate Performance Management, reporting and current best practices.  Effects for firm´s results from implementation of the REMONA modelfaster and more accurate reporting, cost reduction etc.

Fig. 1 .

 1 Fig. 1. The Remona model concept The basic view of the architecture is represented by individual layers integrated in the model. It is a layer of Fig. 1:

Fig. 2 .

 2 Fig. 2. Remona Business Architecture

  Data Model designed for the application and its Business Tasks, o Application Layer that contains business logic of the solution defined in Business Tasks (see above), o Reporting, o Deployment that is describing all mandatory steps that have to be completed if we want to use model in proper way, o Initial parameters of services etc.

Business tasks (Profitability, Planning and Cost Allocations)  Dimensions and Metrics  Application REMONA (software) that is solved from following views: o Architecture, o


Jussi Nikander
email: jussi.nikander@luke.fi

Application of the papiNet-Standard for the Logistics of Straw Biomass in Energy Production

Keywords: Multi-fuel supply chain, Supply chain, papiNet, Straw logistics, Bioenergy ecosystem, Logistics chain

Multi-fuel solutions are an increasingly common set-up in CHP (Combined Heat and Power) plants. Many use also different types of biofuels, such as wood or agricultural products. In Finland, the most prominent type of biofuel in CHP are forestry products, with agricultural biofuel playing only a marginal part. This work investigates the use of the papiNet standard, originally designed for the forestry supply chain, as a possible data exchange format for a multi-fuel supply chain where forestry products are the dominant type of fuel. In the work a model for the data exchange between different actors in the supply chain is described, and the application of papiNet in it is explored. As a result, the papiNet standard is found to be suitable for use with some provisions.

Introduction

One current trend in energy production is the use of biomass in CHP (Combined Heat and Power) power plants. Such systems sometimes use one specific type of biomass, such as wood, but often the systems are designed multi-fuel systems. Common are also solutions where biomass is co-fired together with fossil fuels such as coal [START_REF] Sami | Co-firing of coal and biomass fuel blends[END_REF]. The types of biomass used in energy production can be characterized in several ways. McKendry divides the material by type into woody plants, grasses, aquatic plants, and manure, with grasses further subdivided according to moisture content [START_REF] Mckendry | Energy production from biomass (part 1): overview of biomass[END_REF]. Another way to categorize biomass is to divide it into crops and wastes, with waste coming from three sources: forests, agriculture, and municipal waste [START_REF] Naik | Production of first and second generation biofuels: A comprehensive review[END_REF]. The latter categorization is more suitable for the purposes of this paper, as many biomasses used in CHP energy production are created as by-product or waste product of some other process, such as felling waste or sawdust. There are, however, agricultural biomasses that are grown for use in CHP energy production, such as reed canary grass [START_REF] Burvall | Influence of harvest time and soil type on fuel quality in reed canary grass (phalaris arundinacea l.)[END_REF][START_REF] Lord | Reed canarygrass (phalaris arundinacea) outperforms miscanthus or willow on marginal soils, brownfield and non-agricultural sites for local, sustainable energy crop production[END_REF]. However, despite research and development efforts, cultivation of such energy crops is currently not a particularly wide-spread phenomenon [START_REF] Lindh | Production of reed canary grass and straw as blended fuel in finland[END_REF]. In 2007 the total estimated area for energy crop cultivation in the whole EU was approximately 2.5 million [START_REF] Alakangas | Biomass fuel supply chains for solid biofuels[END_REF][START_REF] Laitinen | Energy from field energy crops -a handbook for energy producers[END_REF] to 5.5 million [START_REF] Panoutsou | Energy crops in the european context[END_REF] hectares out of approximately 109 million hectares. The majority of this area was used to grow crop for biofuel production, such as rape [START_REF] Laitinen | Energy from field energy crops -a handbook for energy producers[END_REF][START_REF] Panoutsou | Energy crops in the european context[END_REF]. Thus, in order to to use agricultural biomass in any significant degree in CHP power plants, by-products, such as straw, need to be utilized.

Forest biomass, as well as solid agricultural biomass, such as straw or reed canary grass, can be directly used in common CHP plants. In case of co-firing plants, different types of fuel are typically mixed together with each other. Such multi-fuel power plant requires the management of multiple different fuel sources, and thus has a need for sophisticated information systems to manage the different supply chains and ensure the availability of fuel. In Finland the most common type of biomass in energy production is forest biomass. However, there is significant interest in exploring the potential of other sources of biomass in energy production, and how these sources could be easily integrated to the current supply chain, which is focused on forest products.

This paper concentrates on the information management of the supply chain logistics of straw biomass in a multi-fuel environment in Finland. The main focus is in investigating suitable means for the different actors involved in the supply chain to be able to exchange data in a machine readable and standard manner. In Finland, the forestry supply chain, which includes the supply of forest biomass for energy production, uses the papiNet standard [17] for data exchange. The goal of this work was thus to investigate whether papiNet could be used to also handle the data exchange needs of the straw biomass supply chain, or if another data exchange format is needed. The research question in this work is "How feasible it is to use forestry data exchange standards to handle straw supply chain information management for multi-fuel biomass power plants".

Materials and Methods

The forestry supply chain is an area of bioeconomy where the integration of software systems and automatic data exchange between different actors is welldeveloped. In the Nordic countries one reason for the level of development is that the supply chain is dominated by a relatively small number of large forest industry companies1 . Their central market position puts these companies in a position to make industry standards for the supply chain. Forestry logistics has at least two important, internationally supported standards: StanForD and pap-iNet. The StanForD (Standard for Forest machine Data and Communication) standard maintained by Forestry Research Institute of Sweden is meant for data storage and exchange between computers in forestry machines [START_REF]Skogforsk. troduction to stanford 2010[END_REF], whereas the papiNet standard maintained by the papiNet initiative is meant for data exchange between actors in the forest and paper products supply chain [17]. In addition to these two, there are other standards used in various nations for a number of different purposes, such as buying and selling timber, or maintaining forest resource maps. As an example, the various national forestry standards used in Finland can be found on a single web page2 .

The current versions of the StanForD and papiNet standards have been implemented using XML, which is currently a very commonly used method in business to business interoperability [START_REF] Lampathaki | Business to business interoperability: A current review of {XML} data integration standards[END_REF][START_REF] Nelson | Interorganizational system standards development in vertical industries[END_REF][START_REF] Nurmilaakso | Xml-based e-business frameworks and standardization[END_REF]. The papiNet standard attempts to cover the supply chain of forestry products as well as possible, and has been adopted for use in several countries [START_REF] Ginet | Standardised electronic data exchange in the french wood supply chain[END_REF][START_REF] Mtibaa | Towards a traceability solution in the canadian forest sector[END_REF][START_REF] Naslund | Supply chain integration: barriers and driving forces in an action research-based industry intervention[END_REF]. The standard covers data transfer needs for different parts of the supply chain from business activities, such as requests for availability or complaints, to measuring, storing and moving the products. The standard also explicitly covers eight product categories ranging from forest wood to book manufacturing and pulp [17].

Currently, the use of straw in energy production in Finland is marginal [START_REF] Lindh | Production of reed canary grass and straw as blended fuel in finland[END_REF] despite active research on the topic [START_REF] Satafood | Biotaloudella lisarvoa maataloustuotannolle (additional value to agricultural production through bioeconomy[END_REF]. However, there is significant potential in energy production with straw, and in Nordic countries there are existing power plants using straw, such as the Fyn Power Station in Denmark [START_REF] Satafood | Biotaloudella lisarvoa maataloustuotannolle (additional value to agricultural production through bioeconomy[END_REF]. Fyn creates 24.5 MW of electricity and 84MW of heat annually by using 170 000 tons of straw as fuel. Total annual straw harvest in Denmark is 5.5 million tons [START_REF] Alakangas | Biomass fuel supply chains for solid biofuels[END_REF]. Currently in Finland, the most ambitious straw power project is the bio-ethanol production plant under construction at Kouvola, Finland, which would consume 330 000 tons of straw to produce 72 000 tons of ethanol 3 .

Typically in straw supply chain it is assumed that the straw is baled upon harvest and the supply chain will handle bales. There have been attempts at transporting unbaled straw in Finland, but experiments showed it to be a worse option than using bales. Typical Finnish balers produce round bales. Rectangular balers, which would produce bales more suitable for the supply chain due to their shape, are rare due to price, weight, and low demand. However, with rectangular bales there would be less wasted space during transport. This work was conducted as part of the Finnish strategic research project BEST -Sustainable Bioenergy Solutions for Tomorrow4 . Part of the BEST project was the development of a biomass virtual terminal, an integrated software solution for managing lots of biomass stored in various locations ranging from large, permanent storage stacks to small, transient roadside piles. The initial goal of the virtual terminal was to be able to meet the future requirements of forestry biomass supply chain in Finland. However, there was a strong need to expand the terminal to also include other types of biomass. Straw was selected as the first case for the expansion of the concept.

As part of the research on the virtual terminal concept, the flows of data between different forest supply chain actors in the Finnish biomass logistics chain were modeled. The constructed model was then reviewed and refined in workshops. This forest biomass model was used as the basis for the inclusion of straw in the virtual terminal. In addition, previous work on the use of straw in energy production was mapped using a literature review and expert interviews. This work acted as basis on the development of a data model for straw supply chain.

Based on the information gained from the forest biomass data model and the expert interviews, the forestry model was modified for handling straw biomass. The straw model was then reviewed and refined using expert opinions, and the information that needed to be transferred between different actors, systems and processes was extracted from the model. The result of the extraction was then used to further review and develop the model. Finally, examples of the data messages included in the model were constructed using the papiNet standard.

The papiNet examples constructed were compared against the model and the information exchange needs in order to analyze the suitability of the papiNet standard for the task. In the analysis, special emphasis was placed on the coverage of the standard, mainly can it be used to depict all the information required, and the suitability of the standard, mainly can all the information required be expressed in a concise and useful manner.

Results

The main result of this work is the model of the communication between different actors and processes in the straw supply chain for energy production, and the analysis of this model. Based on the model and the defined data transfer needs, examples of communication messages using the papiNet standard have been developed. The model has been analyzed using expert reviewers, and its suitability for purpose has been assessed. The model is depicted in Figures 1 and2. The notation in the figures is inherited from the related forestry model, and it has been implemented using the Altova UModel diagram tool.

The black rectangles in the Figures depict the actors and systems involved in the model. There are three primary actors: the energy company, the supply chain, and the farmer. The energy company's ERP system and farmer's Farm Management Information System are also depicted separately in the Figures. The goal of the energy company is to procure fuel for their power stations in order to ensure that the stations can always produce the desired amount of energy, both electricity and heat. The supply chain has been hired by the energy company to transport straw from the farmers to the power stations. The farmers have been contracted by the energy company to cultivate cereals and sell their straw for energy. In a typical situation there is one energy company and numerous farmers involved in the process. The number of supply chain actors is at least one, but can be more. Different actors can, for example, be responsible for different geographical areas.

The different systems and processes in Figures 1 and2 are depicted using two elements that represent different processes in the model. The yellow rectangles are processes that communicate with other processes in the model, and blue rectangles are data management systems or processes that do not directly communicate with other parts of the model. There is one such detached process in Figure 2: the process of cultivating a farm. The numbered steps in the Figures depict various stages of the straw supply management. The arrows in the model depict communication from one process to another, where each arrow depicts one exchange of data. Finally, both the farmer and the energy company have their own information systems that interact with their processes.

Making a Farming Contract

The making of the farming contract and the harvest notification are shown in detail in Figure 1. The process starts with the farmer making a preliminary agreement with the energy company for selling them straw. Based on this agreement, the energy company can create in their ERP farmer database an entry for the farmer, which they then use to store all information about the farmer that they need. Similarly, the farmer can store the details of the agreement to the software system they use to store the farm data. The preliminary agreement acts as a basis for the actual farming contract between the energy company and the farmer. In the farming contract, the farmer and the energy company agree on the approximate amount of straw the farmer is willing to sell. At harvest the farmer will find out how much straw they actually have, and can inform the energy company about how much straw they are capable of selling. The process of making a farming contract will most likely be done primarily using means that are not directly machine readable, i.e. paper contracts. While electronic contracts are possible, the paper contract tradition is still extremely strong and therefore likely to persist for quite a while. From the point of view of the information management, the most important details for the farmer and energy company to agree during the contract making process is the approximate amount and location of straw the farmer is willing to sell. Using this information, the energy company can make preliminary plans for arranging their supply chain to provide them with straw until the next harvest period.

Typically, the machine-readable data transfer in the model starts with the farmer sending harvest report to the energy company (step number 4). Previous communication is likely to be primarily on human-readable documents. The harvest report is a report on amounts and locations, and possibly also moisture percentage of the harvest. Assumption is that the straw will be baled for transport, and thus the basic unit of measurement that needs to be transmitted is the number of bales available. If the baler can also measure the weight and moisture of a bale, further information can also be transmitted. Location is assumed to be either a street address, or GPS coordinates.

Order for New Fuel

The more detailed description of the model continues in Figure 2. The left side of the Figure covers the model from the creation of a new order for fuel to the sending of a notification of straw retrieval to the farmer, while the right side covers the model from straw pickup to the fulfillment of the fuel order. The communication depicted by steps 6 through 8 within Figure 2 happens inside the energy company's organization. The activity begins when the warehouse management determines a need for more fuel (step 5) and sends a order for fuel (step 6) that starts a new fuel procurement process. The most important things given to the new process are the amount of fuel, the delivery location, and deadline for delivery.

The fuel procurement process forwards the order for fuel to the energy company's farmer database to select the loads of straw that would fulfill the order (step 7). If needed, the loss of straw between the harvest and the current time can be estimated using loss modeling, if such is available. Currently, no loss models are in use. The farmer database will send the fuel procurement process information how fulfill the order (step 8). This message contains information regarding straw lots to be retrieved, including the location and owner of each lot, as well as information on the amount of straw.

After the fuel procurement process has gained information on what to deliver to the power station, it can forward the information to the supply chain, which will create a new straw delivery process to handle the pickup, transport, and delivery of the straw. The fuel order that the fuel procurement process transmits to the straw delivery process (step 9) in Figure 2 is a combination of the fuel order (step 6) and the straw data (step 8). The supply chain then accepts the order (step 10). Should the order be rejected, the fuel procurement process needs to react. Possible actions include contacting another supply chain operator, adjusting the order, or advising the power station that new fuel order cannot fulfilled given the criteria.

After the straw delivery process has accepted the order, the next action is sending the farmer an advance notification of straw retrieval (step 11). This message informs the farmer about the location and the amount of straw to be taken, as well as the estimated time when it will happen.

Fuel Delivery

The right side of Figure 2 covers the model from straw pickup to the fulfillment of the fuel order. In the model as part of the straw pickup, the supply chain actor makes a quality measurement, where the weight and moisture of each bale of straw is measured. In case quality measurement cannot be made, the model skips to the retrieval of straw.

The quality measurement process is starts with the straw retrieval process making a quality measurement order (step 12). The important information transmitted in the order is the location, the time, and the type of measurement to be done. If needed, the order can be accepted in a manner similar to step 10. The acceptance procedure is not included in the model). When the measurement has been done, the quality measurement results can be sent to the straw retrieval process, the fuel procurement process, and the farmer (step 13). The measurement results should contain the weight and moisture of each straw bale included in the delivery.

When a lot of straw is picked up from a specific farmer, the straw delivery process sends the farmer a message, which contains information about the location, the time and the amount of straw that has been picked up (step 14). At the same time, the straw delivery process also sends this information to the fuel procurement process (step 15) as well as to the power station (step 16).

When a load of straw arrives at the power station, the supply chain actor will hand it over to the straw reception process. Upon receiving the load, the reception process will send a message to the warehouse (step 17) and to the fuel procurement process (step 18), informing them on the arrival of the new batch of fuel. The message to the warehouse includes the amount of new fuel delivered, while the message to the fuel procurement process informs this process that a specific shipment has arrived. The fuel procurement process updates the farmer database (step 19). If the arrival of straw concludes a specific fuel procurement, the fuel procurement process, and with it the order for fuel, end. Otherwise the fuel procurement process will continue to wait for confirmations regarding the rest of the fuel order.

Discussion

Based on the model described in section 3 and the example papiNet messages created in the work, the usefulness of the standard on the problem of straw supply chain was analyzed using a standard SWOT analysis. Results of the analysis can be found in Table 1. The table is arranged to separately list all the four aspects of SWOT analysis in order to give the reader a quick overview of the advantages and disadvantages of the papiNet standard. More detailed discussion regarding each element can be found in Sections 4.1-4.3 Poor profitability of the sector Existing platforms make it easier to expand the scope of the solution In Finland, the lack of appropriate machinery

Strengths

The papiNet standard includes message types that can be used to deliver all the information the messages require in the process of fuel delivery. Table 2 shows which papiNet message type is used in each step of the process. As can be seen on the table, six different types of papiNet messages have been employed. However, some steps could be handled also by other messages, such as using a DeliveryMessage in step 18. Thus, this is not the only means to implement the model using papiNet. In an implementation of the virtual terminal concept, the message types to be used then need to be decided.

An important part of the data exchange, is the identification of each actor in the process, as well as cross-referencing to all relevant messages in the process. In papiNet all actors are called parties, and each of them needs to have an unique identifier. The standard includes a large number of different types of identifiers, such as the global papiNetGlobalPartyIdentifier and VATIdentificationNumber. The global identifier is an IANA Private Enterprise Number (PEN) 5 , whereas VATIdentificationNumber is the VAT number of the actor. Both are well-suited to act as unique identifiers in the process.

Cross-referencing messages is required for example due to how a single order for fuel may be divided into a large number of deliveries that can be done by different supply chain actors. Thus there must be means to link each delivery instruction to a specific order. In papiNet messages allow for references to other messages, which include all the different message types in the model, and thus the model offers sufficient supporst maintaining cross-referencing. However, in some cases references require an authority to be assigned to them. Many possible authorities are relative to the message, which can make it difficult to pass references along.

As can be seen, the papiNet standard includes data elements that can be used to depict the required information for the supply chain to work. Thus there are rather low barriers for including straw supply chains in the same information system as forestry product supply chains and with papiNet it is possible to create a multi-fuel supply chain information management system.

Weaknesses

A possible problem with using the standard is the use of relative identifiers in many messages. For example, many elements in the standard require defining the actor responsible for assigning the value, such as a message reference. Such are needed, for example, when papiNet is used to send messages between different actors in the same organization. In such case it may not possible to use the PEN or VAT identifiers, as these can be identical for both the sender and the receiver. In such messages, it is possible to use for example the papiNet AssignedBySender identifier, which allows for the use of arbitrary identifiers. However, AssignedBySender is a relative ID, and thus cannot easily be passed along a message chain. The same problem with relative identifiers is also found elsewhere in the standard.

Another problem with the use of papiNet is that the standard does not have any in-built means of describing agricultural concepts or products. The standard has a product description element called <product>, under which different types of products can be described in detail. However, the <product> element supports seven categories of forestry products. Everything else must be described using the other products category, which it is very generic and thus cumbersome to use.

The standard is originally designed for forestry products, and thus the handling of non-forest biomass can, in general, be cumbersome when using it. The values of many attributes in the standard are forestry-related, such as the item-Type -attribute in the <itemInfo> element, which describes the type of item being measured. Many of the possible attribute values are directly related to forestry, such as Log. <ItemInfo> has some general values, such as box, or pallet. However, as these values are very generic, their usefulness is somewhat limited. Some of the values can actually be deceptive in the context of agriculture. One possible value of <ItemInfo>is baleItem, but in the standard this is assumed to be a bale of pulp or paper. Thus using this value for straw bales is, at least in principle, misusing the standard and can lead to confusion in an implementation.

Therefore, while the papiNet standard is a good choice for supply chain data exchange in a business ecosystem where forestry products have a significant presence, other solutions should be considered in cases where forestry products are either not present at all, or have only a minor role.

Opportunities and Threats

The papiNet has significant international support in the forestry industry. The papiNet initiative has over 40 member companies from both Europe and North America, giving the standard a wide-spread and stable industry support. This, in turn, translates to significant geographical coverage in the use of the standard. Therefore papiNet is a safe decision in the sense that there is a strong organization behind the standard that guarantees its future use.

Furthermore, the widespread support fo the standard also translates into platforms that support the use of papiNet. Thus there are both existing platforms in production use where papiNet is supported, as well as people who have experience in working with the standard and implementing it in actual production environments. Thus it is easier to take the papiNet standard into use than try and apply technology which is not as robust or widely used.

However, the dilemmas of what data exchange standard to use, or how to apply them, are relatively minor compared to the problem of making the straw ecosystem in bioenergy production attractive to the various actors. Straw supply chains have been successfully created, as shown by the Fyn Power Station in Denmark, and, in principle, there is interest among Finnish farmers to sell straw for energy [START_REF] Satafood | Biotaloudella lisarvoa maataloustuotannolle (additional value to agricultural production through bioeconomy[END_REF]. However, the amount of income a farmer can get from straw is quite small, as typical price the farmer might get is under 20e per ton, which is a fraction of the current low Finnish grain price of approximately 140e per ton [START_REF] Statistics | [END_REF]. In practice, this makes many farmers think the income is not worth the effort. Unfortunately the straw price given to the producer cannot be increased, or straw would become uneconomical source of energy compared to other fuels [START_REF] Satafood | Biotaloudella lisarvoa maataloustuotannolle (additional value to agricultural production through bioeconomy[END_REF].

Furthermore, an efficient supply chain would require the weight and moisture of the straw to be measured during baling, in order to to give the energy company information about the quality of the harvest. However, current balers in Finland typically cannot do this and the low profit potential of selling straw does not make new investments attractive.

Bale weight is relatively simple to measure even after baling, as this can be done with any tractor which has a scale attached to the front loader. Measuring the moisture of the bale after baling is can be more difficult, however, as it is recommended that bales are wrapped in plastic for storage [START_REF] Lötjönen | Harvest and storage of moist cereal straw[END_REF]. Penetration of the wrap for measuring the moisture would aversely affect the storage characteristics of the bale. There is a similar problem if the moisture content is measured during bale retrieval, if the plan is to store the bales at the power station premises for an extended period of time.

A relatively significant problem in the supply chain is also the fact that most balers in Finland produce round bales. The round shape is problematic in logistics, as it leads to relatively large amount of wasted space between bales. For efficient logistics, large rectangular bales would be better than round ones. However, rectangular balers are rare in Finland, and their large weight can be a problem on Finnish fields.

Thus, the problems in setting up the information systems required are relatively minor ones compared to the other practical problems in using straw for energy.

The biomass Virtual Terminal

The communication model described in this paper is intended to be used as part of a biomass virtual terminal, an integrated software solution for managing lots of biomass stored in various locations. The goal of the terminal is to make it possible to have a single system that can be used to manage all biomass an energy company has intended to use in their power plants. By its very nature, such system requires a large number of independent actors to cooperate and share data. From the point of view of energy company, the situation is a relatively traditional cooperative venture together with a large number of subcontractors. The number of subcontractors required can be large, but there are only rather few different types of actors involved in the process.

The straw logistics process described in this paper contains two types of subcontractors: the farmers and the supply chain actors. The virtual terminal will also require two other types of subcontractors in order to handle forest biomass, the forest harvester contractors and forestry companies. The forestry companies manage and handle the primary forest biomass trade, and sell felling waste and other such products to the energy company. The contractors do the actual forest harvesting. The subcontractors are typically managed either by the energy company directly, or by a specific party the energy company has outsourced their fuel acquisition to. In the straw model the assumption is that the energy company directly manages the subcontractors, as there currently are no actors who would provide such service in Finland. However, should the straw biomass market increase, such actors would most likely appear. Or, alternatively, companies that currently manage forest biomass acquisition would expand their business to cover also straw.

The whole production and supply chain for a co-fired CHP plant can, in reality, grow large and complex. Thus it might be useful to approach the problem as a whole using a virtual enterprise model, or similar [START_REF] Martinez | Virtual enterprise organisation, evolution and control[END_REF]. So far, such overview of the whole process chain has not been made, but could be done in the future.

Similarly, the different types of fuel included in such supply chain can be extremely heterogeneous. Thus, if the biomass virtual terminal would be extended into a complete fuel virtual terminal encompassing all fuel used by an energy company, the papiNet standard in its current form would quickly become inadequate. The element types, possible values, and especially the whole <product> element would need to be expanded further and generalized.

Conclusions

From information technology point of view it is relatively simple to adapt the papiNet standard for the use of agricultural bioenergy chains. The usability of papiNet for straw has been demonstrated in this paper, and similar means can be used for other agricultural biomasses. This is an advantage in an environment similar to the current bioenergy business ecosystem in Finland, where the business is concentrated mainly on forestry biomass. Thus existing logistics systems already use forestry-related standards, such as papiNet. In an environment, where this external motivation for the use of forestry standards does not exist, a new assessment of the existing standards should be done, and some other standard may well be more suited for the task.

Similarly, should the number of different types of fuel handled grow very large, the limitations of the papiNet standard in its current form, will soon be encountered. The standard is designed primarily to handle logistics and business transactions in forestry, and not the energy industry. Therefore other standards may be more suited in such case, or alternatively the papiNet standard would require significant amount of further work.

However, the real barrier for the use of agricultural biomass in energy production is not the technology, but the business. For the farmer, the amount of compensation they get from selling straw for energy is very small compared to the amount of resources and time required for harvesting and storing the product. Furthermore, the additional income gained from this needs to be used to cover the additional need for fertilizers, as straw is no longer used to improve the soil.

Thus, we can relatively easily develop the technological means for including agricultural biomasses in the bioenergy ecosystem, but at least in the case of Finland, it is difficult to make it into a profitable business that attracts farmers.

Fig. 1 .

 1 Fig. 1. The straw supply chain model from making of the farming contract until the harvest notification

Fig. 2 .

 2 Fig. 2. The straw supply chain model from the creation of an order for new fuel, until the delivery of straw to the power station

Table 1 .

 1 Strengths, Weaknesses, Opportunities, and Threats on the use of papiNet for straw logistics in bionenergy context

	strenghts	weaknesses
	Mature, robust technology	Relative identifiers for many elements are
		cumbersome
	Contains all required message types	No support for describing agricultural con-
		cepts
	Capable of expressing the required informa-	Weak support for identifying non-forestry
	tion	actors and concepts
	Sufficient ability to cross-reference informa-
	tion
	Opportunities	Threats
	Significant support in forest industry	May be unsuitable for environments where
		forestry products are not dominant
	Supported in several countries

Table 2 .

 2 The papiNet message types used in each step of the model. Natural language stands for unstructured text documents in natural language, and N/A stands for steps that are not associated with data exchange

	step message	step message	step message
	1 . natural language 8.	DeliveryInstruction 15. DeliveryMessage
	2.	natural language 9.	DeliveryInstruction 16. DeliveryMessage
	3.	natural language 10. BusinessAcceptance 17. DeliveryMessage
	4.	MeasuringTicket 11. DeliveryMessage	18. ShipmentStatus
	5.	N/A	12. PurchaseOrder	19. DeliveryMessage
	6.	PurchaseOrder 13. MeasuringTicket
	7.	PurchaseOrder 14. DeliveryMessage

Metsä group, UPM, and Stora-Enso in Finland

http://metsatietostandardit.wm.fi/en

http://www.sbe.fi

http://clicinnovation.fi/activity/best/

http://pen.iana.org/pen/PenApplication.page